[Openid-specs-risc] openid/sharedsignals: New Issue opened

[Shannon Day]

Yes, other changes can potentially affect a stream beyond its status—such
as configuration modifications, metadata updates, or permissions
adjustments. However, in the current system design, only StreamUpdate
events that carry status information are emitted because these events are
specifically targeted to reflect the state transitions of the stream itself
(e.g., creation, deletion, active, inactive).

Focusing on status allows for streamlined event processing and simplifies
downstream handling, ensuring that components respond correctly to the
lifecycle changes of streams. If other types of updates (like metadata
changes) need to be propagated, additional event types can be introduced,
but for monitoring the stream’s lifecycle, status-focused StreamUpdate
events are sufficient and efficient.


On Tue, Aug 19, 2025, 1:01 PM github--- via Openid-specs-risc <
openid-specs-risc at lists.openid.net> wrote:

> openid/sharedsignals event
>
> Issue opened
> Issue Title: Tx sending a Stream Update Event for stream deletion
> https://github.com/openid/sharedsignals/issues/287
>
> Here is the discussion we had in the WG meeting about this topic: - (Yair)
> The spec says to send a Stream Update event when the status changes. -
> (Yair) Do we need a "deleted" status to send when a stream is deleted? -
> (Thomas) If we don't add a deleted status, how will Receivers know that
> resources should be cleaned up? - (Mike) Does that imply that streams live
> on forever with status "deleted"? - (Yair) No, the stream would be deleted
> and gone. - (Thomas) What happens for Receivers that don't get the event? -
> (Yair) This event is for the benefit of the Receiver. - (Thomas) But that
> means the stream can only be deleted after the deleted event was consumed.
> - (Yair) I don't think the stream should wait for the event to be delivered
> before deleting - (Thomas) Should we use something like the inactivity
> timeout to say the stream should hang around for a specific amount of time
> after the event is sent before deleting itself? - (Shayne) It's a little
> bit strange to think about status of "deleted". I wonder if we want a new
> event, StreamDeleted. - (George) I agree with the idea of a specific event.
> There is no way to guarantee that the Receiver will receive the event, but
> having a mechanism to alert in an optimistic case is nice. - (George) Both
> the Transmitter and Receiver should have some documented logic to determine
> when a stream is no longer active. This new event is an optimization, but
> the fallback mechanisms have to be present as well. - (Yair) What is the
> expectation today for what happens when a stream is deleted? - (Shayne) I
> don't think we have any expectations today. - (Yair) For now, we could send
> a "disabled" status before deleting the stream - (Shayne) I'm not against
> the idea of sending a "disabled" in this case. What does the Receiver do
> when it gets that event? - (Yair) I would expect that getting an unexpected
> disabled status would alert a human operator. - (Mike) Someone might
> trigger a verficiation event which would then return a 404 because the
> stream would no longer exist. Is the expectation that a 404 should cause
> the Receiver to shut down the stream on their end? - (Yair) I would expect
> that the customer or Receiver host would want to trigger some kind of
> investigation - (Shayne) Does the deleted event vs a 404 change the
> customer's behavior? - (Yair) It depends on whether the customer triggered
> the action - (Shayne) A deleted event might be a nice thing for a Receiver
> that requests the deletion. - (Mike) A 204 from the delete request should
> be the thing that tells the Receiver the deletion was successful. -
> (Thomas) What about multiple Receivers on the same stream? - (Mike) It
> feels cleaner to have a deleted event to go out before deletion - (Thomas)
> Possible race condition without some kind of timeout before deleting the
> stream - (Yair) For push streams, that shouldn't be a problem, but poll
> streams do have that issue - (Shayne) One more argument for making this an
> event not a status is that statuses seem to talk about whether events can
> "enter" the stream, not whether they can be broadcasted over the stream. -
> (Yair) Is there any other change that can affect the stream besides status?
> If so, why do we only have StreamUpdate events with status info? - (Shayne)
> Some examples of things that could change - the Tx could add or remove
> subjects, could change the delivery method, could change timeout intervals.
> We don't really restrict the Tx's actions. - (Shayne) What I'm hearing is
> that maybe we want to extend StreamUpdated to cover more than just status
> changes. Then we are not creating a new event type for stream deletion, but
> just adding new metadata to the StreamUpdated event.
> _______________________________________________
> Openid-specs-risc mailing list
> Openid-specs-risc at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-risc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250819/ef120569/attachment-0001.htm>