[HN Gopher] Don't record your social life on an append-only soci...
___________________________________________________________________
Don't record your social life on an append-only social network
(2022)
Author : cristoperb
Score : 64 points
Date : 2023-04-13 19:10 UTC (3 hours ago)
(HTM) web link (www.ctrl.blog)
(TXT) w3m dump (www.ctrl.blog)
| amadeuspagel wrote:
| Worth considering, but the conclusion that permanency is
| "definitely not what you should look for in your social network"
| goes way too far. People use different social networks for
| different purposes.
|
| There are certain privacy features like self-deleting messages
| that you can only get in a closed ecosystem. Does this mean you
| shouldn't use any kind of web-based social media, since everyone
| you communicate with can easily and automatically archive
| everything using a browser extension or userscript?
| sharperguy wrote:
| I find the nostr[1] protocol to be a nice alternative here. The
| core idea is the separation of message content from the relays
| which transport them. So you sign a message and publish it to
| several relays, and then anyone can retrieve your message from
| any of the relays where it is published.
|
| As opposed to Mastadon, your identity is tied to your pubkey
| rather than the instance that you created your account on. The
| difference to Scuttlebutt is the differentiation of relays vs
| clients, and the lack of chaining messages together in the
| "blockchain"-like structure.
|
| The result is a fairly simple protocol which is fairly low
| latency and seamless for many applications compared to other
| decentralized solutions.
|
| [1]. https://nostr.com/
| canadiantim wrote:
| Isn't nostr still an append-only solution?
| csdvrx wrote:
| So you mean, like Hacker News past 2 hours?
| WakoMan12 wrote:
| [flagged]
| csdvrx wrote:
| Not sure I should have vouched for your comment but it was a
| funny illustration of the principle being discussed, and
| therefore relevant.
| SllX wrote:
| Sometimes it's worth checking comment history before
| vouching.
| csdvrx wrote:
| oopsies :)
|
| I don't like to check comment history, as I prefer to
| avoid passing judgement based on past behavior, but here
| you're rigt, I should have.
| SllX wrote:
| Same, and I only figured this out very recently too. Just
| passing it on. :)
| karaterobot wrote:
| > The technology that powers SSB is entirely different from
| Twitter and Mastodon. You don't need to register an account
| anywhere to get started. Your identity isn't a username and
| doesn't depend on a domain name or service provider. Instead,
| your username is a meaningless cryptographic hash that consists
| of random-looking numbers and letters. Your friends only need to
| know your hash to follow you, and you can keep it as public or
| private as you want.
|
| I'm not familiar with SSB. And, to me, this article's headline is
| five words too long (harumph)
|
| Question though: Does this imply that I can follow someone
| without them knowing about it if their address hash gets leaked?
| If so, in what way could it meaningfully be described as being
| private? I assume there's some way to control who you broadcast
| to, or approve someone who follows you, and this description is
| just not mentioning it.
| robryk wrote:
| > in what way could it meaningfully be described as being
| private?
|
| You can broadcast encrypted statements:
| https://ssbc.github.io/scuttlebutt-protocol-guide/#private-m...
|
| ~Everyone can tell how many of these you sent, when, and how
| large were they, but not to whom (incl. how many recipients
| they had unless there were too many and you had to send
| multiple copies[1]) or what was in them.
|
| [1] The copies will still be unlinkable, but if someone sends 5
| messages of ~same size within a second, it's a pretty good
| guess that they're sending 5 copies of the same message.
| gropo wrote:
| twetch uses the bie1 encryption protocol on a plaintext
| blockchain to allow for append only data that can be retracted
| from view.
|
| twetch.com
| Mizoguchi wrote:
| Exodus = 0.2%
| iLoveOncall wrote:
| "Blockchains are useless, more at 5"
| wmf wrote:
| Bluesky's AT Protocol has made some progress on using Merkle
| trees while still allowing content to be deleted.
| genpfault wrote:
| (2022)
| dang wrote:
| Added. Thanks!
| [deleted]
| i-use-nixos-btw wrote:
| Completely unaware of this social network. What problem, exactly,
| is a blockchain based social network trying to solve? Proof of
| origin? A conversational paper trail?
|
| The latter would be interesting for areas where conversations
| should be on the record, however in cases that people want their
| conversations off the record they'd just use a side channel. The
| UK govt communicates using WhatsApp for Christ's sake.
|
| So it'd need to be something where both parties fundamentally
| benefit from the ability to verify that a post, or a
| conversation, took place. Where would that even apply?
| grapesurgeon wrote:
| [dead]
| joemi wrote:
| > What problem, exactly, is a blockchain based social network
| trying to solve?
|
| I think the problem it's trying to solve is: "How can we mix
| social networking with blockchain?"
| carlmr wrote:
| Maybe betting? Both sides are usually interested in recording
| the bet.
| aftbit wrote:
| AFAIK it was intended to support the use case of being
| occasionally connected to the internet (one author spent a lot
| of time on a small sailboat in the south Pacific), while
| maintaining an order of messages.
| grey_earthling wrote:
| > What problem, exactly, is a blockchain based social network
| trying to solve? Proof of origin?
|
| (SSB is blockchain in the strict sense, but there's no proof of
| work or anything like that. Each feed is its own append-only
| chain with its own private key.)
|
| For SSB, the aim was to be able to gossip feeds via untrusted
| intermediaries, with patchy network connections all round, and
| be sure that the intermediaries haven't added, changed or
| removed any posts in the feed.
|
| The protocol's designer lives on a boat in New Zealand, and
| other collaborators live in remote areas in different time
| zones.
|
| One adjustment to the protocol that seems to me like a quick
| win (but presumably has some technical hitch I can't see, since
| I don't recall anyone suggesting this) would be to not include
| the post's body in the "block" (in the message itself that gets
| hashed and signed by the next message), but rather as a "blob"
| (essentially an attachment) which others don't need to download
| in order to verify the feed. That way old messages could be
| effectively forgotten if all peers co-operate (and no-one took
| a screenshot, etc).
| rinor wrote:
| I'm working on something in this space, though god knows if
| I'll ever finish it. And that's one of two approaches I
| considered to that problem. Another is to have a signed
| deletion marker saying something to the effect of "there was
| a block here with hash d9841a, but now there isn't anymore,
| and I'm its replacement".
| evbogue wrote:
| > One adjustment to the protocol that seems to me like a
| quick win (but presumably has some technical hitch I can't
| see, since I don't recall anyone suggesting this) would be to
| not include the post's body in the "block" (in the message
| itself that gets hashed and signed by the next message), but
| rather as a "blob" (essentially an attachment) which others
| don't need to download in order to verify the feed.
|
| There's nothing to prevent you from taking this route, you
| just sign a blob hash instead of an entire message object.
|
| I work on an experimental SSB-like-protocol in my spare time
| that does exactly what you've suggested:
| https://github.com/evbogue/bogbook
|
| I don't know if this makes the network forget more, but the
| aim is to reduce the time it takes to sync and get started.
| Vendan wrote:
| It's about as much blockchain as git is blockchain, so... not
| really blockchain at all...
| an_ko wrote:
| To my understanding, it allows messages on the network to have
| a total order, even when fully decentralised. Without a hash
| chain, clients could not tell what order events happened in,
| and might display them ordered differently, which would change
| a conversation's meaning.
|
| The traditional alternative is logical clocks, but a malicious
| participant could forge those, so they're not suitable for a
| fully distributed system run by random users.
| mwattsun wrote:
| I deleted 12 years of Facebook posts after downloading a backup
| one by one. This was before they had multiple deletes. It took me
| a few weeks so I did it when I was bored. What's funny is that
| you can't actually delete everything, because something from the
| past will show up again. Just one or two things. I assume when
| databases located around the world sync up there's a few things
| that didn't get deleted.
| klabb3 wrote:
| Mostly agree. You can have strong cryptography even with
| mutability/overwritability. You can simply issue soft deletes by
| issuing a tombstone write.
|
| However, you always risk someone else (like a scraper) storing
| messages including your signature forever. Deleting is virtually
| impossible for practical communication purposes. Best you can get
| is "I promise you I deleted my copy and thus wont distribute it
| further".
| roundandround wrote:
| I'd generally consider that different because whatever people
| scrape could be randomly reassembled but its not forming a
| canonical proof. A social platform that digitally signed
| content to have irrefutable proof of what you scraped would be
| closer and that would probably be adding the anti pattern they
| criticize for little reason.
| klabb3 wrote:
| It sounds right, but would you mind spelling out the full
| conclusion? The level of indirection is a bit high for my
| lazy brain.
|
| To me public communication has the trade off between trusting
| the communications platform (like most social platforms
| today) vs trusting the end user (signed messages). If you
| have trusted end users, scraping a third party repo of
| "forever history" becomes more plausible, as they can both
| prove that you(ish) signed it and are unlikely to respect
| your request to delete their copy. Is this different from
| what you're saying?
| Dalewyn wrote:
| "The internet never forgets."
| 123sereusername wrote:
| also, wash your hands after using the toilet.
| jfax wrote:
| >Your identity isn't a username and doesn't depend on a domain
| name or service provide
|
| Like a tripcode?
|
| >Instead, your username is a meaningless cryptographic hash that
| consists of random-looking numbers and letters.
|
| Ah
| grey_earthling wrote:
| In SSB it's a public key. Most users announce their own display
| names (which needn't be unique) and some clients let you set a
| pet name for other users (like a phone's contacts list).
| koch wrote:
| While not anything blockchain-based, I had a similar thought of
| just doing social media through a single text file that you can
| add to/remove from whenever, and re-post the whole thing[0].
| Literally HTTP POST it.
|
| Edit, amend, add, delete, schedule, etc., all from a single text
| file. I haven't worked on it in a few weeks but I intend to get
| back to it soon.
|
| [0] https://post.mw
| tenebrisalietum wrote:
| Somewhat of a precedent exists: classic UNIX mbox files.
|
| I guess it would be fine if indexed separately. Edits to data
| past a certain age are fairly rare.
| dddw wrote:
| Cool stuff
| squiggy22 wrote:
| I went to try this out only to read the words 'download the
| software'.
|
| Good luck with that. Even the Firefox plugin requires some
| additional setup. Frictionless it ain't. By a long stretch.
|
| Sigh.
| bee_rider wrote:
| Sounds like the goal of the article was achieved? You didn't
| record your social life on an append-only social network.
___________________________________________________________________
(page generated 2023-04-13 23:00 UTC)