Accountability for publishers and relays

[nostronaut]

Aim: permit accountability for publishers and relays.

follows the discussion in this issue

Publisher's weight using key-longevity

This proposal requires a chain of events. This can be an optional protocol built on top of Nostr.

Instead of chaining events directly, using the event_hash like in Secure Scuttlebutt, use merkle mountain range (MMR) as an append only vector commitment for events (the same data structure used by opentimestamps in NIP-03) to enable fast verification (only a few events needed for proof of membership in the MMR).

In a Nostr event, add a field in tags that includes the previous_event_hash and the previous_root_hash of the MMR.

Special relays and clients implement the extra protocol on top of Nostr. To enable the goodness, a relay must at a minimum store the last prev_hash and MMR prev_root_hash for each pubkey and its sequence number, and verify the new event follows from the last one, else reject event, etc, being super lightweight, and able to detect missing events from publisher. In contrast, an archival client might store and verify the entire event history, and may serve data to light clients to construct their light proofs. A client implementing this protocol behind a relay dropping events can tell events are being lost.

The idea is to calculate a weight for the author's pubkey in a similar way as one calculates the amount of POW for a blockchain, here the weight of the author being the sequence number of the event, that is the number of events that key signed sequentially. Up on the stack, one might estimate the weight of the event based on the weight of the author and of the people that references the event. For example, when long-lived, active identities interact, the event thread becomes a heavy-weight event-thread. This might be useful for page ranking.

A basic form of moderation is still needed, for example, relays shouldn't replicate events from a spammer with a long and provable career of spamming etc.

When correctly combining the current protocol with NIP-03, one might be able to create a notarised "side-chain". As analogy to Bitcoin, one could think of this chain as containing one UTXO (the last event) that gets consumed when a new event builds on top of the last event.

[nostronaut]

since it looks like there is some interest in this, we implemented a demo client here https://github.com/nostronaut/mmr-nostr

[earonesty]

note: we already have previous event hash in fields. it's called "reply to" and an "e" tag. unfortunately this protocol is very sybil attackable without a squared social distance weight.

simply looking at the people you follow and calculating a rating based on squared social graph distance.

then you cannot trick it. because it's all people you follow, or people they follow. a spammer cannot sneak in.

then you can use any scoring system (like this one!), and use a weighted sum for reputation across many vectors. "comms score, is people who reply, like and negative score is people who mute and block, chain score is long chains of replies" ... but again, those events must be weighted as above... a person with no connection to you liking some post is, by definition, meaningless and must be "unscored". and it always must be ... or the system is trivially abused.

fortunately social graphs are, typically, well connected, easy to cache and easy to subscribe to.

[nostronaut]

first and foremost, the proposed authentication system should not be used by everyone, because it is too commiting, and may be exploited as legal evidence against normal people.

on the other hand, it could be used by companies, journalists, polititians, or in general reliable sources of information ("oracles") trying to attest to the state of the world.

note: we already have previous event hash in fields. it's called "reply to" and an "e" tag.

right, while hashchain works, in practice it has bad scalability, as it requires clients to download and validate all events in order to validate the last one. we learned this from bitcoin and SSB, and there is even a comment on this on nostr-protocol repo

we want more than only an "e" tag, we want an "e" tag and an additional merkle root. the MMR root hash works as a vector-commitment/timestamping/accumulator with short merkle paths to all previous messages. if u r familiar with p2p social networks, they often talk about partial replication of events, and this is what the tree structure accumulating hashes optimally enables -- you may be able to replicate / store / serve leaves holding events of parts of the tree you care about, while ignoring the rest of the tree, while still being able to serve data and create merkle proofs etc.

unfortunately this protocol is very sybil attackable without a squared social distance weight.

we assume that you mean it is vulnerable to sybil attacks because people can do long-range attacks, that is show up with one or many long linear history of events from nowhere, correct us if this assumption is wrong. nonetheless in combination with a social network, the MMR event commitments become a widely-witnessed time-stamping service. People must not score the linear history of events that arrived all at once, but the one they verify over time, as a witness of the implicit time-stamping service they run together. if people are caught having parallel histories, that must be reported including the cryptographic evidence of the wrong-doing. opentimestamps (plus additional commitments) may be able to replace the widely-witnessed time stamping service

simply looking at the people you follow and calculating a rating based on squared social graph distance. then you cannot trick it. because it's all people you follow, or people they follow. a spammer cannot sneak in.

sure, all for this, we would even be more idealistic and say people shall only connect to trusted (own/friends/contacts) relays/tunnels to fetch events. then u have a friend to friend network, and the users who are not able to be replicated on ur trusted relays don't even exist for you.

then you can use any scoring system (like this one!), and use a weighted sum for reputation across many vectors. "comms score, is people who reply, like and negative score is people who mute and block, chain score is long chains of replies" ... but again, those events must be weighted as above...

exactly, mute and block, our opinion, are better expressed together with delete events, force disconnect and cease to exist in our view of the network.

a person with no connection to you liking some post is, by definition, meaningless and must be "unscored". and it always must be ... or the system is trivially abused.

we wouldnt state it that bluntly, purely using heuristics. a person may share similar topics of interest to us while far or outside of our social graph. our love for a topic link us together. in the p2p setting, that may mean peers that interact with or replicate a large subset of the data we replicated. Or more abstractly peers that subscribe to the same topics as us.

although we are soulmates with them, we havent yet met, very sad :( lol

fortunately social graphs are, typically, well connected, easy to cache and easy to subscribe to.

hope this helps with the general picture, open for discussions

we thank the scuttlebutt community for most of these insights

[earonesty]

i don't think there is anyone fully disconnected from anyone else socially. not sure that even exists in this world. i would be willing to bet that if you add at least 100 honest contacts (people you actually would follow on twitter or whatever), you're 100% connected at some arbitrary depth. this may be segregated by language (a bit), but i doubt it. is it unreasonable to ask people to add 100 contacts before they get good ratings of others?