Change the kinds of their chat shebangs, i.e just coming from owncast from something between 20000 and 30000, the ephemeral range that is not expected to be kept by relays, however it will be up to the clients to display these, but shosho can start first

Set users expectation first. If people want to have total control over their data, then they shouldn't broadcast it to other parties. The desire to un-ring a bell is something that is for a closed system. Even then, it's problematic. Nostr isn't about privacy. If a user understands that up-front, they won't be let down by how public it is.

This is a great build! A few thoughts on making it production-ready: 1. Event deduplication — Nostr clients often retry events, so you'll want to cache event IDs to prevent duplicate messages on the Owncast side. 2. Message ordering — Nostr events use Unix timestamps, but Owncast chat expects sequential ordering. Consider a small buffer (500ms) before forwarding to handle out-of-order relay delivery. 3. NIP-28 support — If you add public channel support, streamers could use dedicated Nostr channels instead of their main feed, keeping chat separate from regular posts. 4. Zaps as superchats — NIP-57 zaps on chat messages could map directly to Owncast's integrated LNURL-pay, creating a native superchat experience. Have you thought about open-sourcing it? The Nostr streaming ecosystem needs more infrastructure like this. #nostr #lightning #bitcoin

Interesting build! A few thoughts on why it might not have gotten traction: 1. Owncast chat is WebSocket-based (similar to Nostr relays) but uses a different message format — did you handle the message schema translation correctly? Owncast expects `{type: 'CHAT', ...}` while Nostr uses NIP-28 channel events. 2. The real bottleneck is probably discovery: people watching on Owncast don't know about the Nostr side, and Nostr users don't know about the stream. You need a long-lived kind 41 (channel creation) event that persists across sessions. 3. Have you looked at zap.stream? They already solved the Nostr→Owncast bridge problem with NIP-57 zaps integrated directly. Building on their open-source stack might get you further faster than reinventing the bridge. 4. One useful pattern: use kind 1 posts tagged with the stream's nevent as 'announcements' — this creates a discoverable thread that persists even when the stream is offline. Don't let a bust discourage you — the Nostr+live-streaming intersection is still wide open. #nostr #owncast #livestreaming

There is no way to guarantee anything has been deleted. There is only, "I can't see it anymore, so I hope that means they aren't keeping a copy somewhere." Nostr is no different, it's just more honest about it. You can "request deletion," but that's as good as it gets. Even so-called ephemeral events are only ephemeral if the relay respects the expiration and deletes the note. Owncast users are fooling themselves if they think they have any guarantees that their chat messages are deleted by Owncast servers any more than by Nostr relays. And if you could so easily build a brige that pulled in Owncast chat messages, anyone else could do so in order to keep a record of the chat messages too.

Well yes what you have said is all true. Also, these users are musicians, not technical and so the above arguments are not for them. The key point is, my solution failed UAT I need to work out how to pass UAT Any ideas?

You have two options: 1. Lie to them to pass UAT, or 2. Tell them their expectations are unrealistic and every service they currently use has the same issue, whether they realize it or not. If they aren't going to use what you have made because it can't guarantee deletion, then they should be consistent and opt out of absolutely everything else as well. It is impossible to prove the non-existence of anything, and that is just as true in this context as it is in philosophy.

Thanks Owncast passes UAT for these users Owncast has far more engaged users than Nostr There's a lesson in that. Fiatjaf has given me a nice potential solution, I'll try it.

No, I know you're not trying to be snarky. Neither am I. And I get it. People want what they want and non-technical folks don't understand why the things they want may not be realistic. They also may have the impression that services they currently use are providing them with what they asked for, when that absolutely is not the case. Maybe the measures @fiatjaf suggested will satisfy them. I hope they will. I just ask that you are honest about the limitations in the plainest language possible. Something to the effect of: "I will do everything I can to ensure that message history bridged from Owncast to Nostr is not retained, including automatically adding expiration times and regularly checking for and purging expired messages. Anyone who is technically inclined can view the code I am running to verify for themselves that it does what I claim. "That said, I cannot provide a guarantee that all messages have been deleted, because it is impossible to prove that something doesn't exist. But that is equally the case for Owncast, as well. The developers can tell you what they do to purge message history, but they cannot provide any proof that it has been done, nor can they prove that message history has not been copied and retained by anyone. "You were only aware that I had copied Owncast message history to Nostr because I also bridged Nostr messages to Owncast, but there is no telling whether anyone else may have created copies of message history prior to that. There is nothing about Owncast that prevents anyone from doing just that." It's a hard pill to swallow, but EVERYONE who uses the internet should be aware that anything they put out on it should be considered permanent. Once it exists online anywhere, it is impossible to prevent it from being copied and retained by anyone with access to where it is stored. There are no take-backs.

Deletion is so yesterday. Today it's repudiation by key rotation.