Thread

Thanks man, appreciate your words 💛 Let me know if you play with this :)

Read through the spec, and it's very well written and thorough. I made one suggestion here:

GitWorkshop.dev

Decentralized github alternative over Nostr

Thanks man appreciate it 🧡 Just answered back 👌

Yes, I'm aware. It's chosen consciously as the snapshots are some sort of app specific data

I mean, so is everything. But in this context app specific means "not intended to be interoperable"

Yes exactly, seems appropriate for me

Then why write a spec?

To define what kind to use. I didn't consider that polluting the kind list was a good idea specifically for an event that might have very different shapes as every state machine state snapshot might have different shapes, and picked the only agnostic kind in nostr for the only replaceable event defined in the spec.

Eh, it's not polluting, that's what kinds are for, is to partition the protocol. But I see what you mean, if the schema varies there really is not a lot of interoperability.

Yes, this is a complex problem and it took me some time until I felt comfortable with any solution. Currently, the spec relies on the fact that users and state machines can define their own model of trust. The key here is that in the state machine definition event, 'state custodians' are defined. These state custodians are legit sources that are established in the state machine definition event and are something you can agree upon with the participants in the state machine. There might also be cases where one of the state custodians is a third-party service that offers to be a 'watchtower.' But as I mentioned, there is nothing imposed in the spec, so for each use case, users can choose the model that best suits their requirements. Then, every transition references the previous one, creating a DAG, and the state snapshot references the head, so there we have a deterministic tie-breaker. There is also a section in the spec about this: '7. Conflict Resolution and Chain Integrity' that explains all of this in detail. Let me know what do you think about this, and thanks for the feedback

Yeah, that was the section I was referring to. Multiple watchtower-type custodians helps (similar to relays), but they're still picked by the creator of the state machine, so they could be malicious. Nostr works because truth is relative, but in this case users can't pick their own custodian without risking an unresolved fork

Can you imagine a better way to solve this issue? My rationale behind this is that users agree beforehand who are going to be the state custodians, who at the end are the ones responsible for keeping the state coherence. The creator of the state machine is not transcendental; for example, if we both are going to participate in some sort of process, contract, or any other thing modeled by a state machine, we can both be state custodians and have the same responsibility. The creator doesn't matter at this point. Unresolved forks are a risk, but I think this model correctly places the responsibility on the participants, the state custodians, and does not enforce any specific requirements. I see these state machines as a way to define an agreement declaratively with all its possible states and conditions. This is a low level primitive to build things on top, and requirements for specific use cases like strong security of the state and dispute resolution should be application specific

Use a blockchain haha I think this model probably has a lot of possible failure modes, especially when it comes to actual implementation. In the case of two participants, where a fork means the contract is over, that can work. But usually the function of a smart contract is to force agreement on something. Anyway, I'm skeptical, but don't let that stop you. It's an interesting project. If we can indeed figure out a way to have consensus on nostr it would be germane to my key rotation nip, which makes some massive compromises on centralization in order to work:

GitHub

Key migration by staab · Pull Request #2137 · nostr-protocol/nips

This NIP was sketched out in a session at nostr.xxx. It's based on @pablof7z's original migration proposal with some elements from #2114. D...