calle 💯 on nostr

Open in Damus

@calle 💯 1779869572

Nobody else seems to care but I think nostr finally needs a Hash Chain event kind or tag that is enforced server-side:

- To add a new event to the chain, you MUST reference a previous event. If the referenced event does not exist, you get an error.
- Only one event can reference another event. If an event has already been referenced before, you get an error.

IMO (almost) solves the biggest issue with nostr which is the fact that you never know if the data you have is complete and it allows atomic updates of data. Suggestions for improvements of this idea welcome.

433❤️17👀1👍1😱1🧡1

calle 💯 · 6d

nostr:nprofile1qqs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75sprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszythwden5te0xy6rqtnxxaazu6t09uqs7amnwvaz7tmj9enrw73wd9hj7zq9s8u this could make nip60 actually work

calle 💯 · 6d

I looked at bluesky and they have this shit and this makes it *so* much easier to work with.

Derek Ross · 6d

This was discussed a lot several years ago and I don't recall the reasons for the pushback at the time. I do agree that without this change, we do get lost replies and lost data. It's hard to reconstruct the whole conversation. That said, Outbox/Inbox does help here. nostr:npub180cvv07tjdrrgpa0j7j7...

Raison d'État · 6d

PLEASE NO! This is what SSB does, and it exacerbates network flakiness. That be why I'm here...

This is a Git-shaped problem. You mught not need a new kind. You want a relay-distributed repository with deterministic branch management: content-addressed objects, explicit parentage, fast-forward rules, detectable forks, and a current tip that relays can announce.

Sjors Provoost · 6d

The second requirement sounds like a DoS problem for clients, desperately having to look for an unclaimed event. And it'll be different per relay. The first requirement also has the problem that each relay may have a different view, but at least you could first query relays to find out. Enforcing t...

Leo Wandersleb · 6d

The proposal: Like replaceable events but you have to be explicit which event you are replacing? I would or maybe publicly did call that versioned event. You get a chain and relays should retain older versions up the chain for a while, so when a buggy client nukes your contact list, the nuking even...

Colby Serpa · 6d

Solved this years ago but no one cared. You create a Merkle tree of your post hashes, as a catalog for your account. The posts can still be individual, but the tree serves as a guide for if anything is missing. You don’t need a chain. Problem is, two devices trying to update the tree (or your ch...

SatsAndSports · 6d

How would this work with unreliable relays? If I can't find the event that you reference, is it because you've fabricated a reference, or because I simply don't have access to your earlier event?

Technical Debt · 6d

CRDTs could be a viable alternative for this (for those complaining about holes breaking SSB and stuff).

This is interesting for specific use cases. Have you read the nostr state machines I wrote some time ago? It uses dag as you mentioned https://gitworkshop.dev/npub1gzuushllat7pet0ccv9yuhygvc8ldeyhrgxuwg744dn5khnpk3gs3ea5ds/relay.ngit.dev/nsm/tree/master/state-machines-on-nostr.md Also have you chec...

calle 💯 · 5d

This does not (can't) prevent forks across multiple relays because relays would have to coordinate for this. I won't try to fix an unfixable problem. The bigger issue is that we don't even have consistency for ONE relay, let alone multiple. For multiple relays, you can still improve (not fully fix)...

Shouldnt be hard nostr:nprofile1qqszrq3cgvfe89vadjrp0gaa3xfs82txpx6y5ezwjuufzqu20h5xytgppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7gcjh9t