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
Converge community messaging onto a single pubsub topic — the default shard (32) — and drop the non-protected shard (64). Community control messages (request/cancel to join, request-to-join response, user kicked, shared-addresses response) are currently published on shard 64, which keeps two shards alive and complicates moving to the Logos Delivery Messaging API (content-topic-only auto-sharding).
We can't just switch publishing to shard 32: deployed clients filter-subscribe to community control content topics on a fixed (shard, content-topic) pair (filter delivery is keyed on the exact pair), so a light client listening on shard 64 would silently miss anything published on 32. Hence a staged rollout.
Stages
Migration follows this strategy. Content on shard 64 needs to be migrated to shard 32, assuming we keep the existing content on shard 32 as is.
Phase 2 is planned to be the first release with logos-delivery instead of go-waku
To integrate auto-sharding, implement a hot-fix in logos-delivery enabling overriding the shard to send on and subscribe to.
The override is needed as long as the network pins shard index 32 (auto-sharding for a single shard otherwise lands on index 0); it can only be dropped by a follow-up migration to content-topic-derived sharding.
We MAY monitor the network traffic on shard 64 and extend the migration if traffic didn't significantly drop yet after Phase 2.
Receive paths already cover shard 32 for the other parties (member personal topics default to shard 32; control-node admin filters cover 32 and 64), so the only receive change needed in Phase 1 is the community broadcast topic.
Goal
Converge community messaging onto a single pubsub topic — the default shard (32) — and drop the non-protected shard (64). Community control messages (request/cancel to join, request-to-join response, user kicked, shared-addresses response) are currently published on shard 64, which keeps two shards alive and complicates moving to the Logos Delivery Messaging API (content-topic-only auto-sharding).
We can't just switch publishing to shard 32: deployed clients filter-subscribe to community control content topics on a fixed
(shard, content-topic)pair (filter delivery is keyed on the exact pair), so a light client listening on shard 64 would silently miss anything published on 32. Hence a staged rollout.Stages
Migration follows this strategy. Content on shard 64 needs to be migrated to shard 32, assuming we keep the existing content on shard 32 as is.
Notes
logos-deliveryinstead ofgo-wakulogos-deliveryenabling overriding the shard to send on and subscribe to.