Problem: can't view current state #1
Description
Problem: can't view current state
The nostrocket state machine (engine) publishes the current state to kind 10310 replaceable events, in reply to the nostrocket Current State event (currently 0255594820a3ddc5b603d4e37ba6b2325879aebec401b86f9d69f5fd3864c203 for testnet/dev mode)
The relay currently in use for this is nostr.688.org
Possible solution:
Implement a basic frontend with flamewerk (because @KevinGaethofs wants to do this and he's using flamewerk).
The frontend would use either fiatjaf's or Pablo's nostr library (but don't think pablo's one is public yet) and:
- subscribe to the root event
- render the current state
- reactively re-render the current state when it gets updated with a new event
State is transmitted as JSON in the event content. It follows this convention:
{<mind name>:{data}, <mind name>:{data}, ...}
Nostrocket engine is a state machine that is composed of many smaller state machines for each type of function. For example, identity is in one state machine, and shares are in another.
These smaller state machines are called "minds".
Every time any state is updated, the entire state of nostrocket is published to a kind 10310 event. This will probably change later because the amount of data could get pretty big and we only want to update the parts that change, but for now it's easier to keep things simple by just putting everything together in a single event.
I'm rapidly adding more minds to nostrocket, but right now only the identity and replay protection minds are available.
Here's an example event with the current state:
{"identity":{"b4f36e2a63792324a92f3b7d973fcc33eaa7720aaeee71729ac74d7ba7677675":{"Account":"b4f36e2a63792324a92f3b7d973fcc33eaa7720aaeee71729ac74d7ba7677675","Name":"gsovereignty","About":"Just testing another 1","Picture":null,"UniqueSovereignBy":"1Humanityrvhus5mFWRRzuJjtAbjk2qwww","CharacterVouchedForBy":null,"MaintainerBy":"1Humanityrvhus5mFWRRzuJjtAbjk2qwww","Pubkeys":null,"OpReturnAddr":null,"Order":0}},"replay":{"b4f36e2a63792324a92f3b7d973fcc33eaa7720aaeee71729ac74d7ba7677675":"57cbe8a5f32fb3aa7f498bd6bf9a7dac5a013f3a49225e5e2545e91dfba2e75e"}}
In this event we can see that there are two minds: identity and replay.
The replay mind is to prevent replay attacks. When sending an event that causes a state change, the event MUST include a r tag of the ID of the previous event (which caused a state change) from this user. So events that cause a state change cannot be replayed because the ID of the last event would not be the same again. The state of the replay mind is simply a list of pubkeys and the ID of the last event (which caused a state change) sent from that pubkey. The next event MUST include a single r tag with the last event ID or it will be rejected.
The identity mind tracks a tree of users to raise the cost of sybil attacks. Anyone who is in the tree can add new people to it.
UniqueSovereignBy is the account that added this person to the tree. It would be cool to display this as some kind of flow graph thing.
There's also a tree of maintainers. These are people who can merge pull requests etc.