Mix refactor #18
Mix refactor #18
Conversation
|
You can see the README rendered here: https://github.com/tinySSB/tiny-ssb-spec/blob/b36f140ba10185a5b0e4c071f0a0b663800fb81c/README.md |
| Where: | ||
| - `DMX`: The 7-byte WANT_DMX calculated as described above | ||
| - `payload`: BIPF-encoded array containing offset and sequence numbers | ||
| - `padding`: Zeros added to bring the packet size up to 120 bytes |
There was a problem hiding this comment.
@tschudin Is there any reason for the padding? Since the payload is BIPF encoded this seems unnecessary to fill up the whole 120 bytes.
There was a problem hiding this comment.
Hm, would have to look up the code. If padding really is used, then the "max" in the length arrow should go away.
There was a problem hiding this comment.
Actions
- Someone to review code + update
README.md
Outdated
|
|
||
|
|
||
|
|
||
| ## 3. Feeds |
There was a problem hiding this comment.
Why is this section not at the beginning? The GOSET doesn't really make sense to a newcomer if the ideas of Feeds, Feed-id's, DMX's and packets aren't already described.
There was a problem hiding this comment.
I see your point: so we should have a new section, after "1. Design Decisions", and before "2. Replication". Let's called it "1' Single Author Append-only Logs (Feeds)" and let it contain
1' (will become 2) Single Author Append-only Logs (Feeds)
new text: Secure Scuttlebutt as well as tinySSB are based on append-only logs (feeds) implemented by hash-chains.
1'.1 Feed Structure and Concepts
see existing text (currently it's in section 3.1)
1'.2 Global Feed Replication
new text: Conceptually, the communication primitive implied by feeds is that of a global broadcast: any feed extension should potentially be received by everybody, worldwide and eventually. To this end, peers in (the global) tinySSB network replicate all feeds by listening on any updates coming in and forwarding them to all neighbor peers which have not yet seen that update. In reality, this is not scalable wherefore replication is selective: each peer announces for which Feed ID it wants to receive updates, using the WANT replication protocol (see Section X.Y).
The current section "3.2 DMX Mechanism" must be revisited and change its number, for sure: but is the place still fine, does it need a new intro?
There was a problem hiding this comment.
I agree.
I'd like to keep the "details" of the feed in here and have a "primer" with just core concepts at high-level overview earlier. Could even be conveyed with some diagrams?
Actions
- add section called
## 2. High-level Overview(can be renamed) + renumber document - make a branch + PR which adds content to high-level / basic intro
README.md
Outdated
|
|
||
| The `packet_type` code exists to support different types of packets. Currently | ||
| there are only main-chain and side-chain packet types | ||
| ### 3.4 Feed Limitations and Considerations |
There was a problem hiding this comment.
All of this section seems unnecessary in the middle of the protocol guide before describing side chains (which solve these limitations). I'm not sure it's even necessary.
There was a problem hiding this comment.
agree, we can remove 3.4.1 without loss. Reference to sensor data belongs to the top, anyway
There was a problem hiding this comment.
Agree.
I think the other sections other than 3.4.1 were important and good to highlight for new people.
Actions
- 3.4.1 has been removed
- @nanomonkey can you confirm that resolves your issue?
README.md
Outdated
| <!-- | ||
| src: https://github.com/ssbc/tinySSB/blob/fee99079ac2820711e1e853cba0e7aacc8765fea/android/tinySSB/app/src/main/java/nz/scuttlebutt/tremolavossbol/tssb/Replica.kt#L378-L403 | ||
| --> | ||
| The GOSET protocol does not inherently protect against spam. A malicious peer could potentially flood the network with many different Feed IDs, causing the GOSET to grow unnecessarily large. Application-level filtering or trust mechanisms may be needed to mitigate this. |
There was a problem hiding this comment.
Suggestion for an additional sentence:
One such mechanism, which is currently being developed, is called 'bubbles' where a GOSET's set of Feed IDs can only be enlarged by a cryptographically signed "add" message as part of an application-level membership management protocol.
There was a problem hiding this comment.
@tschudin I am explicitly excluding all mentions of speculative features. If you'd like to document Bubbles, please put it an issue.
WHY: This is a hard-line I'm holding because we MUST get the actual working spec done. There are so many places that we have noticed "oh this could be improved". If we touch each of these as we try to get the base down I fear we will never finish <3
Actions
- @tschudin to mark this as Resolved (if OK)
remove scaffolding files
| ## 2. High-level Overview | ||
|
|
||
|
|
There was a problem hiding this comment.
Responding to this comment thread:
NOTE: This name is a placeholder, I wanted to make it easy for people to add an intro/ design-decisions/ high-level overview. I used AI to renumber all the section headings (and references).
Please feel free to rename, move this around etc.
Actions
- fill in content
This PR follows roughly the sketch that Nano + Mix came up with. I wrote this synthesis with the aide of AI, going through and manually editing things to correct. Interestingly I think it actually caught a bug on the upper limit of the GOSET size (it's 255 not 256)
This branch is still missing initial areas:
Will need to reintegrate and write those