You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
**State Change Request**: a *note* requesting a change to the current nostrocket state, for example a Merit Request, logging a Problem, adding a pubkey to the Identity Tree, etc.
24
+
**note**: a nostr event.
24
25
25
-
**Consensus Chain**: a linked list of notes called [Consensus Notes](https://github.com/nostrocket/NIPS/blob/main/Rockets.md#consensus-event). Each note in the list points (with a labelled `e` tag) to at least one *State Change Request*. We build our local state by parsing these State Change Requests against the Nostrocket Unprotocol.
26
+
**State Change Request**: a _note_ requesting a change to the current nostrocket state, for example a Merit Request, logging a Problem, adding a pubkey to the Identity Tree, etc.
26
27
27
-
**Hard State**: this is the state which exists as a [Consensus Chain](https://github.com/nostrocket/NIPS/blob/main/Rockets.md#consensus-over-state) and SHOULD be eventually consistent across all participant's instances of a Rocket.
28
+
**Consensus Chain**: a linked list of notes called [Consensus Notes](https://github.com/nostrocket/NIPS/blob/main/Rockets.md#consensus-event). Each note in the list points (with a labelled `e` tag) to at least one _State Change Request_. We build our local state by parsing these State Change Requests against the Nostrocket Unprotocol.
28
29
29
-
A *State Change Request* that indends to modify *Hard State* only does so when someone with *Votepower* within that particular Rocket includes it in their *Consensus Chain*.
30
+
**Hard State**: this is the state which exists as a [Consensus Chain](https://github.com/nostrocket/NIPS/blob/main/Rockets.md#consensus-over-state) and SHOULD be eventually consistent across all participant's instances of a Rocket.
30
31
31
-
This type of state should be used sparingly. Any state that doesn't require a high degree of consensus among participants should *not* use Hard State.
32
+
A _State Change Request_ that indends to modify _Hard State_ only does so when someone with _Votepower_ within that particular Rocket includes it in their _Consensus Chain_.
32
33
33
-
Hard State is currently used for state that is in the critical path to Votepower: Rocket creation; Merit requests, votes on merit requests, transfer of merits to other pubkeys.
34
+
This type of state should be used sparingly. Any state that doesn't require a high degree of consensus among participants should _not_ use Hard State.
34
35
35
-
**Hard State Change Request** is a *State Change Request* intended to modify *Hard State*.
36
+
Hard State is currently used for state that is in the critical path to Votepower: Rocket creation; Merit requests, votes on merit requests, transfer of merits to other pubkeys.
36
37
37
-
**Soft State**: There is no consensus over this state and it is not included in a Consensus Chain, but it can be considered *eventually consistent enough* for most nostrocket activity. Examples of where it's currently used: Identity Tree, Problem Tracker (logging new problems, modifying problems, etc).
38
+
**Hard State Change Request**is a _State Change Request_ intended to modify _Hard State_.
38
39
39
-
**Soft State Change Request**is a *State Change Request* intended to modify *Soft State*.
40
+
**Soft State**: There is no consensus over this state and it is not included in a Consensus Chain, but it can be considered _eventually consistent enough_ for most nostrocket activity. Examples of where it's currently used: Identity Tree, Problem Tracker (logging new problems, modifying problems, etc).
40
41
41
-
**Session State**: This is for convenience only, it is local to the browser and not persisted as notes. The only current example of this in nostrocket is the current user's profile, which we use for producing notes etc.
42
+
**Soft State Change Request**is a _State Change Request_ intended to modify _Soft State_.
42
43
44
+
**Session State**: This is for convenience only, it is local to the browser and not persisted as notes. The only current example of this in nostrocket is the current user's profile, which we use for producing notes etc.
43
45
44
46
## How it fits together
47
+
45
48
All Nostrocket notes SHOULD point to `note1r0cketrztzx06l3uxd4c2j86fxsfvfls8klsd3aylm38hsqewtyqyp7wj7` so they can be found easily.
46
49
47
50
Hard State begins with a `kind 15171031`[Rocket Ignition Event](https://github.com/nostrocket/NIPS/blob/main/Rockets.md). Nostrocket itself is a Rocket created by one of these events.
48
51
49
-
The pubkey that signs a Rocket Ignition Event is called the *Ignition Pubkey*. The Ignition Pubkey that creates a new Rocket always begins with a Votepower of `1` (only applicable within that particular Rocket).
52
+
The pubkey that signs a Rocket Ignition Event is called the _Ignition Pubkey_. The Ignition Pubkey that creates a new Rocket always begins with a Votepower of `1` (only applicable within that particular Rocket).
50
53
51
54
As the Ignition Pubkey is the only pubkey with Votepower when a new Rocket is created, anyone wanting to view the current Hard State for that particular Rocket should begin by following this pubkey's Consensus Chain, adding and removing further pubkeys along the way as the state of the Rocket changes (the client does this automagically). For additional mallorysistance, users can add their Bitcoin node details to validate OP_RETURNS signed by pubkeys with votepower.
52
55
53
-
Before adding State Change Requests to their Consensus Chain, a pubkey with votepower MUST validate the request against the Nostrocket Unprotocol (encoded into Oxygen logic) within the context of the current global Hard State AND their current subjective view of Soft State.
56
+
Before adding State Change Requests to their Consensus Chain, a pubkey with votepower MUST validate the request against the Nostrocket Unprotocol (encoded into Oxygen logic) within the context of the current global Hard State AND their current subjective view of Soft State.
54
57
55
-
Thus, while there's no consensus over Soft State, it's still somewhat relevant (but not critical) to consensus over Hard State.
58
+
Thus, while there's no consensus over Soft State, it's still somewhat relevant (but not critical) to consensus over Hard State.
56
59
57
60
Soft State is simply updated by Soft State Change Requests if they pass local validation after being received from a Relay. This validation can involve validation against the Nostrocket Unprotocol, the current Hard and Soft state, and user settings.
58
61
59
62
## Note Sources and Routing
60
-
Everything in Oxygen is *Note driven*. These notes come from relays, and are handled differently depending on whether they are *Consensus Notes*, *Hard State Change Requests*, or *Soft State Change Requests*.
61
63
62
-
First, we subscribe to all Relays using all relevant filters. Then we buffer, route, and handle the incoming notes appropriately.
64
+
Everything in Oxygen is _Note driven_. These notes come from relays, and are handled differently depending on whether they are _Consensus Notes_, _Hard State Change Requests_, or _Soft State Change Requests_.
65
+
66
+
First, we subscribe to all Relays using all relevant filters. Then we buffer, route, and handle the incoming notes appropriately.
63
67
64
-
We take the stream of notes from our Relays, filter out anything that doesn't look valid, and buffer the result in mempool.
68
+
We take the stream of notes from our Relays, filter out anything that doesn't look valid, and buffer the result in mempool.
65
69
66
70
### Hard State
71
+
67
72
We listen to the mempool for any valid Consensus Notes (signed by a pubkey with votepower in our current Hard State AND points to that pubkey's last Consensus Note for that particular Rocket). We find the Hard State Change Request that this Consensus Note has included in an `e` tag with the label `request`, and then we fetch that Note from mempool (it SHOULD be in mempool). We handle that Hard State Change Request. If it fails, we halt and catch fire. If the currently logged in user has votepower, we publish Consensus Events to add these Hard State Change Events to our own Consensus Chain at this time.
68
73
69
74
We keep repeating this until there are no new Consensus Notes. Each pubkey can also publish their latest Consensus Note ID and height in a replaceable event so that we know when we've reached the tip. We keep listening for these Consensus Notes and handle them whenever they come in.
@@ -73,10 +78,11 @@ The **Consensus Lead** is the pubkey with the highest Votepower from the set of
73
78
If we (the currently logged in user) has the Consensus Lead, then once we've reached the current tip of a valid Consensus Chain, we start producing Consensus Events to add any waiting Hard State Change Requests (in mempool) to our Consensus Chain (after validating them of course). We do not update our local state directly during this process, we instead wait for our own Consensus Notes to arrive from a Relay and handle them as per the above. This is to keep the logic all in the same place and make things more simple.
74
79
75
80
### Soft State
81
+
76
82
We can handle Soft State Change Requests asynchronously in the background at the same time as Hard State Change Requests.
77
83
78
84
We listen to mempool for all seeminlgy valid Soft State Change Requests, and simply handle them by validating them against the Nostrocket Unprotocol in the context of the current Hard and Soft state.
79
85
80
86
### Best Practices
81
-
* If a Note sucessfully causes any kind of State to change, remove it from our mempool, and add it to a list (or cuckoo filter) of notes that have been handled, so that we don't handle them more than once.
82
-
87
+
88
+
- If a Note sucessfully causes any kind of State to change, remove it from our mempool, and add it to a list (or cuckoo filter) of notes that have been handled, so that we don't handle them more than once.
0 commit comments