I've always been a fan of freenet, I think it's an extremely elegant system. The problem is potentially storing and forwarding data you vehemently disagree with as a user.
(Same issue occurs with relays in nostr, but at least that's opt-in)
Discussion
Is there somewhere I can go to understand it? I've talked to Ian Clarke on multiple occasions (most recently yesterday, which sent me down this rabbit hole), but he does a terrible job of explaining what it would look like in practice.
What do you mean in practice? The network exists and there's several social media platforms built on it.
"twitter like"
Last I checked up on it, it had no database persistence so that really limited its usefulness imho
Probably the oldest, it's essentially a forum system.
Both operate on the concept of following other ids, and web of trust. Happy to elaborate/clarify, I'm not sure how deeply to explain it.
There was a very interesting WoT plugin that was intended to undergird future applications, but I don't know if it ever reached completion: https://github.com/hyphanet/plugin-WebOfTrust it was iirc academically interesting if nothing else for web-of-trust with transitive trust.
Rambling that is probably redundant but I don't know how much you've read so far:
The whole system is built around recursively searching the network for different keys: content keys and signed keys (keys as in key-value store).
Content keys are obviously derived from the content of their data, and signed keys are derived from the signature. Layered on top of signed keys are "updatable signed keys" that are actually just a convention for retrieving the latest version of a signed key by searching subsequent versions (in fact they are different keys with a -1, -2, ... -N suffix)
FMS and Sone both work by "following" an identity's updatable key, which will be updated with an index of their latest posts, and possibly profile data (I forgot exactly how each works, but they're slightly different, and incompatible with each other)
When you make a request for a particular key, intermediate nodes on the route to where that key *should* end up will keep an LRU of requests, and if the key ends up being crated while they have retained that request, they'll forward the result, and hopefully it will end up being sent back to your node in very short order like a notification (otherwise your node will periodically poll and should see it later)
so, just to be clear, most of those concepts are repeated in the nostr protocol
event ID = content hash
signature = on content hash
user identity = public key
scanning the web of trust = #coracle
haha lol! on of the few, just had to put that in at the end
oh yeah one big difference
they used RSA, we use EC
the signature data on such old systems was unweildy... most notes are barely 5% of the cost of the signature and keys
and i should add that in theory we could probably not lose a lot of security shaving another 16 bytes off signatures
it has got me thinking about the idea of making a really raw, simplified version of nostr
like, imagine there is just events, created_at, with content, and a kind, no tags
tags could be subsumed into NIP-32 labels, so you can add them concurrently by clients instead of bundling them together with the event
make the encoding binary, so that all events are a uniform format, the data (content), then the hash of the data, then the signature on the data, everything in binary, no escaping, only a varint length prefix on variable length fields (ie content, everything else is fixed)
you could shrink down the signature field to 48 bytes because it's really unlikely that such a massive data set it's worth trying to mess around with forging signatures, events fly past a a million miles an hour, so a 1/4 reduction in signature security is probably not that big a deal because most of the time it is worth nothing, and this protocol doesn't certify monetary transactions, so it doesn't need to be as strong, and it needs low bandwidth more than it needs such high security as required for money
the real reason why json was used as the message encoding for nostr in the first place was the inventor was a python/django (probably) dev who was used to using this as a message format, as most web apps use json as a message format, as they natively decode it
and the reason why tags are in the event are because hashtags and to reduce the complexity of searching for hashtags for a twitter like experience
these are not necessary to the fundamentals
i'm gonna start campaigning to strip down the event format, remove tags and propose a compact 48 byte schnorr signature and a simplified binary encoding that will at minimum halve the bandwidth cost of nostr
and probably come up with a way of making a protocol translator that securely bridges between a more simple binary format and the source events so that we can start to move forward with a much simpler strategy of building this thing...
it's just thought at this point, this will eventually metastasise into awhole thing
i can think of no better reason to stack sats than to be able to participate in building a really good social network protocol, nothing makes me more excited than making information flow uncontrollable
Nice! That's helpful, I'll look into those projects. Ian always talks in such an abstract way about contracts and delegates it's hard to see how that bridges to content storage and discovery.
There's also a channel on irc, though even back in the early 2010s it was pretty dead. They recently rebranded to hyphanet so it's probably #hyphanet on libera.chat