Another aspect of #2 is that the size of the queue and of the printer cluster will grow substantially - rather than tens of printers, there may be hundreds or thousands (or more!) and similarly so with jobs / queue items.
Lots of peers
[x] New peers that join should not overwhelm RAFT consensus - handled via pubsub
[x] Adding a new peer should not noticeably increase background network bandwidth (i.e. no constant status reports; only when queried) - handled via pubsub / leadership-only polling
[x] When a peer goes dormant for too long (minutes?), it should be removed from RAFT and reassigned (assuming it's a member of the consensus group). Any held locks should time out if not renewed. avoided with discrete list of electable peers
Lots of jobs (queue items)
[ ] When the queue is large, it should automatically shard into multiple pieces. Those pieces are then handled by printers that are auto-assigned the shards based on a hash of their ID.
Lots of queues
[ ] When there are hundreds of thousands of queues, the results will not fit nicely into a single DNS entry, nor even potentially a single IPFS entry. The registries should allow indirect references to other registries.
[x] There should be some way of estimating peers connected to a queue - done probabilistically
[ ] There should be a way to estimate how many queue items there are
Note: not done yet as sharding must be implemented first
Lots of users/permissions
[x] Adding another user should not bloat the core data structure - done because no central user registry
[ ] Users should retain minted tokens that delegate control, signed by some authority. These tokens will have a TTL and must be renewed.
Another aspect of #2 is that the size of the queue and of the printer cluster will grow substantially - rather than tens of printers, there may be hundreds or thousands (or more!) and similarly so with jobs / queue items.
Lots of peers
Lots of jobs (queue items)
Lots of queues
Lots of users/permissions