SSB chain of updates

[Emad Elsaid]

in the README I noticed this :

It insists on having a chain of updates from a single user, which feels unnecessary to me and something that adds bloat and rigidity to the thing — each server/user needs to store all the chain of posts to be sure the new one is valid. Why? (Maybe they have a good reason);

I think the reason here is lying by ommission. a server can ommit/remove a post or an update and send the rest. the client receiving the updates won't know there is a missing part/post/update. having the chain connected will allow clients to detect any missing information.

[nostronaut]

First and foremost, chaining events should not be enforced for everything, so the way it currently is done looks right. Chaining events is more like a higher level protocol played on top of Nostr's protocol.

Adding to what @emad-elsaid said, the linked-list (hashchain of events) also adds accountability for the publisher, as they can't misbehave without potentially being caught. Example of misbehaviors of a publisher include: telling different stories on different parts of a fragmented network or changing past opinion retroactively.

A publisher with a long, linear history of events, that a reader can use to verify the reliability of the source, is super important for creating a "don't trust/verify" kind of reputation for publishers.

Additionally if using something like opentimestamps once in a while for notarization of events, a publisher effectively creates a bitcoin-side chain with its own chained events.

I can envision calculating reputation in a similar way one calculates the amount of POW for blockchain. But even more interesting, when reputable entities start interacting, the event thread of interactions becomes a heavy-weight event-thread, useful for page ranking.