Skip to content

Add SWIP-draft: BPS-lite — single-publisher brokered broadcast - #111

Open
acud wants to merge 1 commit into
masterfrom
swip-bps-lite
Open

acud wants to merge 1 commit into
masterfrom
swip-bps-lite

Conversation

@acud

@acud acud commented Sep 15, 2026

Copy link
Copy Markdown
Collaborator

A standalone single-publisher profile of the design space SWIP-60 (PR #104) covers: one broker, one publisher, N subscribers, one hop.

A cohort is a topic and a topic is a SOC address, so authorship needs no credential, no publisher list and no authenticated handshake — the ANCHOR address check re-establishes it from the signature on every message. The publisher role is bound to the opening stream and transfers on re-Open; the cohort's lifetime is that stream, which removes orphan cohorts and bounds Open as an allocation primitive.

Specified standalone rather than as a profile of SWIP-60, with the protobuf inline and no compatibility claimed in either direction. It answers three questions SWIP-60 leaves open (dedup horizon, cohort lifetime, Open as an unbounded allocation primitive) and drops closed rather than restating a confidentiality claim an unauthenticated handshake cannot support.

The two specs share the pubsub/1.0.0 protocol id, so the handshake carries the compatibility story: SWIP-60's field numbers are reserved, not reused, which is what lets a BPS-lite broker refuse a full-spec Open outright instead of silently decoding it with fields dropped.

Note the one divergence that can fail silently for implementers: BPS-lite's ANCHOR applies its address constraint unconditionally, where SWIP-60 relaxes it under an explicit publisher regime.

A standalone single-publisher profile of the design space SWIP-60 (PR #104)
covers: one broker, one publisher, N subscribers, one hop.

A cohort is a topic and a topic is a SOC address, so authorship needs no
credential, no publisher list and no authenticated handshake — the ANCHOR
address check re-establishes it from the signature on every message. The
publisher role is bound to the opening stream and transfers on re-Open; the
cohort's lifetime is that stream, which removes orphan cohorts and bounds Open
as an allocation primitive.

Specified standalone rather than as a profile of SWIP-60, with the protobuf
inline and no compatibility claimed in either direction. It answers three
questions SWIP-60 leaves open (dedup horizon, cohort lifetime, Open as an
unbounded allocation primitive) and drops `closed` rather than restating a
confidentiality claim an unauthenticated handshake cannot support.

The two specs share the pubsub/1.0.0 protocol id, so the handshake carries the
compatibility story: SWIP-60's field numbers are reserved, not reused, which is
what lets a BPS-lite broker refuse a full-spec Open outright instead of
silently decoding it with fields dropped.

Note the one divergence that can fail silently for implementers: BPS-lite's
ANCHOR applies its address constraint unconditionally, where SWIP-60 relaxes it
under an explicit publisher regime.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E99KGsCW7dyKudy2WbpRco

@zelig zelig left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

review is not yet finished. submitting it so far nonetheless for discussion.

## Simple Summary

One broker, one publisher, many subscribers, one hop. A publisher opens a topic on a
broker and pushes single-owner chunks; everyone else connects and reads. Nothing else.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A publisher must explicitly connect to the broker and has the exlusuve right to publish messages. Just like with all subsequent modes, messages are of a shape of single owner chunks. In this specific case these chunks must be higher-index versions (updates) of a feed with the topic (the cohort topic bound to the feed). All other joiners of the cohort are subscribers.


## Abstract

BPS-lite is a real-time broadcast protocol in which a cohort is a topic and a topic is

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BPS-lite is a real-time broadcast protocol a kind of push notifications on a channel that participants can subscribe to and a restricted set of participants can publish on.
Each channel defines its own cohort (a set of nodes), which are connected through a unique central broadcaster node, the broker. In BPS-lite, each node in the cohort will be directly connected to the broker, hence the moniker single-hop.

Comment on lines +25 to +31
a single-owner chunk address. The peer that opens a cohort is its publisher for as long
as that stream lives; every other peer is a read-only subscriber. Authorship needs no
credential, no publisher list and no handshake authentication: under the `ANCHOR`
binding the topic already names the only key that can produce a chunk hashing to it, so
authorship is re-established from the signature on every message. The cohort's lifetime
is its publisher's stream, which removes orphan cohorts and bounds `Open` as an
allocation primitive.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure i understand this (allocation primitive) but yes Open (open should be interpreted in terms of the connecting node, open connection to the channel, maybe we should call it Join) can create the channel for the broker.

Each channel is uniquely identified by a cohort specification. Turning it around, the cohort specification must contain all information that can distinguish channels, and exclude stuff that can change without changing the integrity of the cohort (secondary publishers).

Open message includes the cohort spec, if someone sends an Open message to the broker node, then the cohort spec is compared to existing open channels. IF one matches, then the candidate is trying to join if not then the channel is opened.

is its publisher's stream, which removes orphan cohorts and bounds `Open` as an
allocation primitive.

It is a deliberate subset of the design space [SWIP-60][swip60] covers, specified as

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

subset it really is , and should not deviate though.


It is a deliberate subset of the design space [SWIP-60][swip60] covers, specified as
its own document rather than as a profile: the wire format below is complete, and where
BPS-lite differs from SWIP-60 — most importantly in making `ANCHOR`'s address

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, so the ANCHOR first of should not be the first of all :) IT must be feed
What is relevant here is single explicit publisher in which case the messages are (supposed to be the ordered updates of a feed.


### Handshake

Publisher-first. The publisher fixes the cohort; subscribers join it.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, anyone (so a subscriber also) can open, join a channel.
Note that if the joiners are not admins, they cannot publish (if they do, protocol violation), so the channel only has minimal resource demand, in fact only an entry in the broker nodes channels map.
There must be an inactivity deadline, so there is no trolling with opening a lot of channels and squat the broker node capacity with bogus idle cohorts.
If the subsciber has no active subscriptions, it can be disconnected.
Similarly, there must also be a maximum channel number per node connection so that a node cannot overwhelm the host broker with newly joined bogus channels while keeping a bonding legit one open.


A `Publish` is accepted iff, in order:

1. it arrived on the stream that opened the cohort;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A published SOC received by the broker is valid if
-!!! the ID of the SOC is an int > feed cursor

  • suubstituting the ID with H(topic|int) the msg validates as a SOC
  • and its owner is one of the publishers (in our case of singleton, the admin).

4. the wrapped CAC's BMT root matches its payload;
5. the CAC address is not in the cohort's dedup window.

Failures 1–4 are protocol violations: the message is dropped, counted per peer, and

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all failures are protocol violations and result in stream cleanup,
disconnect and blocklisting (ONLY if you are the broker).

already failed.

On acceptance the broker enqueues a `Broadcast` on every subscriber stream in the
cohort, and on the publisher's own stream if it requested loopback.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is no loopback ever

orphan cohorts and any reclamation policy, and it bounds `Open` as an allocation
primitive: a peer can hold only as many live cohorts as it holds open streams.

### Dedup

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no dedup , see SWIP-65 how we handle missed items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants