add SWIP-60: BPS singlehop — brokered broadcast pub/sub, base protocol - #104
add SWIP-60: BPS singlehop — brokered broadcast pub/sub, base protocol#104zelig wants to merge 1 commit into
Conversation
Base SWIP of the Broadcast Pub/Sub (BPS) family — the decomposition of the monolithic PubSub SWIP (PR #93) into work-package-sized SWIPs. Companion wire spec: assets/swip-60/bps.proto (singlehop concrete, multihop control frames reserved). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
|
||
| // What the topic binds to (see epic: "What does the topic bind to?"). | ||
| enum TopicBinding { | ||
| TOPIC_BINDING_UNSPECIFIED = 0; |
There was a problem hiding this comment.
what does this semantically mean? why is this a legitimate value that can be used?
|
|
||
| // Who may author (see epic: genesis dimensions). | ||
| enum PublisherRegime { | ||
| PUBLISHER_REGIME_UNSPECIFIED = 0; |
There was a problem hiding this comment.
what does this semantically mean? why is this a legitimate value that can be used?
| TopicBinding binding = 2; | ||
| PublisherRegime publishers = 3; | ||
| bool history = 4; // deliver matching chunks from the local store | ||
| bytes admin = 5; // 20-byte eth address; set iff EXPLICIT_* |
There was a problem hiding this comment.
if EXPLICIT_LIST is this then a concatenated list of ethereum keys?
| EXPLICIT_SINGLE = 1; // opener is admin and sole publisher (live streaming) | ||
| EXPLICIT_LIST = 2; // admin dictates who the other publishers are | ||
| IMPLICIT = 3; // authorship implied by the topic binding (PO constraint) | ||
| ALL = 4; // every peer publishes (gossipsub-equivalent cohort) |
| bool history = 4; // deliver matching chunks from the local store | ||
| bytes admin = 5; // 20-byte eth address; set iff EXPLICIT_* | ||
| uint32 po_min = 6; // proximity order for implicit bindings (default 16) | ||
| uint32 cap = 7; // max direct streams the broker accepts for this topic (0 = broker default) |
There was a problem hiding this comment.
why should a 3rd party be able to control the number of connections on a remote peer? what if the number is too large for the remote node to accept?
| message Broadcast { | ||
| oneof frame { | ||
| Soc handshake = 1; // first frame on a stream: full SOC identity | ||
| DataFrame data = 2; // subsequent frames: signature ‖ span ‖ payload only |
There was a problem hiding this comment.
why split the same chunk to multiple messages? you're also overloading the protocol code to do the message sequencing/buffering/etc... seems really unnecessary. also if you assume just one stream per topic then essentially you're coercing the applications to manage multiple streams between the same two peers continuously - why not multiplex everything over the same stream?
There was a problem hiding this comment.
while the single/multiple stream part is debatable, i'm not sure we need to skimp out on these few bytes that the chunk carries - it really doesn't save much, and then if we want to do single/multi stream management, we don't have to break the message format
| oneof frame { | ||
| Soc handshake = 1; // first frame on a stream: full SOC identity | ||
| DataFrame data = 2; // subsequent frames: signature ‖ span ‖ payload only | ||
| Ping ping = 3; // keepalive; parent measures RTT off the echo |
There was a problem hiding this comment.
who needs this information? we already measure rtt using other means. not sure why this message is needed
|
|
||
| ## Out of scope (deliberately) | ||
|
|
||
| Multihop relaying and referral (bps-multihop), reorganisation policies (SWATCH, SPORE — |
There was a problem hiding this comment.
i would also add to this: remove multi-publisher setup from this iteration. it can be added later and just adds more review surface to deal with at this moment.
| enum PublisherRegime { | ||
| PUBLISHER_REGIME_UNSPECIFIED = 0; | ||
| EXPLICIT_SINGLE = 1; // opener is admin and sole publisher (live streaming) | ||
| EXPLICIT_LIST = 2; // admin dictates who the other publishers are |
There was a problem hiding this comment.
i would get rid of this for a first iteration
| // --------------------------------------------------------------------------- | ||
|
|
||
| // What the topic binds to (see epic: "What does the topic bind to?"). | ||
| enum TopicBinding { |
There was a problem hiding this comment.
nit: i find this whole thing really confusing and not very approachable and i wonder if this even makes sense to do in a first iteration. "pubsub" is very dumb in this sense - it usually does not give you different topic semantics. here, a topic could have different semantics and input validation according to its "type" which makes for a much more complex API surfaces for users later on...
2 participants
Base SWIP of the Broadcast Pub/Sub (BPS) family — the decomposition of the monolithic PubSub SWIP (#93) into work-package-sized SWIPs.
What it specifies: the smallest complete BPS protocol — one broker per topic, direct long-lived p2p streams, an explicit per-topic connection cap, SOC-only messages verified end-to-end. A cohort is fully described by a
CohortSpecof genesis parameters; modes are parameter combinations, not an enum. Companion wire spec:assets/swip-60/bps.proto(singlehop concrete; multihop control frames reserved).Deliberately out of scope (own SWIPs): multihop relaying/referral, reorganisation policies (SWATCH, SPORE), bandwidth incentives, broker discovery (SWIP-58 MEX, #103), history delivery, implicit-publisher event sourcing.
Relation to #93: this SWIP absorbs its Milestone 1 plus the mode system (reframed as genesis parameters); Milestone 3 was already extracted as SWIP-58 (#103). Implementation groundwork: bee #5435, bee-js #1151.
🤖 Generated with Claude Code