A queue for each PqP participant
The first PqP Worker can find or create a participant’s queue, establishing the provisioning step for queue-assisted peer communication.
Create the place a peer can be reached
We have implemented the first queue-provisioning path for PqP. A request to the Worker looks for the participant’s existing queue and returns it when present. If no matching queue exists, the Worker creates one and returns its identifier.
This is an early building block for Peer-Queue-Peer: give a participant a place through which another client can make contact. A browser client may disappear when a device sleeps or a session closes. A queue gives us infrastructure on which to investigate communication across those interruptions.
Keep provider administration in the Worker
The Worker performs the queue lookup and creation against the provider API. The client receives a queue identity rather than the provider’s administrative credential. An existing registration can reuse the same queue instead of creating a new resource for every request.
The initial registration uses an email-derived queue name. That is a prototype convention; stronger authentication, ownership, and lifecycle rules are needed before this becomes a durable identity contract.
Provisioning is the first step
The implementation establishes a repeatable way to provision queue resources. Sending, receiving, authenticating peers, and handling retries still need their own contracts. Queue creation alone does not tell a sender whether another client has consumed a message.
Our next work is to connect this resource lifecycle to the client and define the message path. The Web 5.0 investigation begins with that division of responsibility: clients perform application work, while shared infrastructure helps them become reachable.