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
