Developers can do whatever the fuck they want and there’s nothing you can do about it until you start paying them nostr:note1he2xfa25mg72x04ce57zgymvd9svg67nxvenj2nl0yvnh67vm6aqlwk0u6
That makes sense, so the TCP connection is used to request the retransmits?
When I was looking at this earlier today I came across a draft for multicast extensions to QUIC which looked interesting. I haven’t read the document completely but it does look like it includes recovery mechanisms for dropped packets. It needs to operate in conjunction with a unicast QUIC connection.
https://datatracker.ietf.org/doc/draft-jholland-quic-multicast/
You could do it via TCP, yes
For my design, it starts with subscribing to the multicast stream
You then initiate a TCP connection to the source as a “management” connection, you get the latest packet ID
For a low-latency high-throughput system, you see if there are any packet ID gaps and request.
If you go low-throughput, you may include constant empty messages (which will increase B/W, and higher rate of empty messages = faster recovery from loss)
You can also do a client ack system if you do not have a very high amount of clients for lower B/W usage
You also have buffer memory for retransmits, and that can run out, so clients that cannot recover fast enough need to start over (causing complete loss of the stream)
Many people would have seen nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s 's note about Notedeck supporting multicast relays. As a network engineer, I found this interesting, but I'm sure there were people wondering what multicast is or how it works so I thought I'd have a go at writing an educational note to try to explain the operation of multicast as simply as possible. It is a complex topic so I’ve limited it to a very simple network and IPv4 only.
I've created a diagram that shows the three types of traffic found on a network - unicast, broadcast and multicast. Most connections are unicast with one host sending packets directly addressed to another host that receives them. This is how most communication occurs across the Internet.
Broadcast packets are sent to a special broadcast address (the last IP address in subnet, in this case 192.168.1.255) and are flooded to every host within the LAN. Broadcast traffic is used for things like discovery of devices and for DHCP when a device is first obtaining an IP address. Broadcast traffic is "noisy" as the packets are sent to every device, even if the device does not need the traffic.
Multicast is a way for one device to send packers to many other "interested" devices at the same time. The advantages of this is that the packets only need to be transmitted by the sender once and those packets are then only forwarded by the switch only to devices that want to see the traffic. Common uses for multicast are CCTV systems, IPTV, and IP telephony music on hold systems. It is also used by Apple and other devices for mDNS device and service discovery.
Multicast traffic is identified by a multicast group IP address in the range 224.0.0.0-239.255.255.255 (239.255.100.100 in my diagram). Each host that wants to receive the multicast traffic will listen for packets on this address. Internet Group Management Protocol (IGMP) is used to co-ordinate group membership. In order to join a multicast group, a request is sent by the host to an "IGMP Querier". The IGMP querier may be a router or some switches have this functionality. The switch listens to the IGMP messages (IGMP snooping) to build up a table of which switch ports has devices that want to see traffic to a multicast group address and the multicast packets are then sent out those ports.
There are some considerations when using multicast. Many cheap, unmanaged, switches don't support IGMP so will treat multicast traffic as broadcast. Packets still reach the destination but the benefit is lost as they are flooded out all ports. There can also be issues with multicast on some WiFi networks. Finally, because multicast is 1-to-many, it needs to use UDP rather than TCP. This is relevant for the Nostr use case as it requires a different protocol to websockets that is used for connections between clients and relays. 
There is also concerns about events being dropped in transit, especially with WiFi congestion leading to high packet loss
I have tried designing a reliable one-to-many reliable ordered communication protocol on multicast. It is an entirely different can of worms
Why are you using reflect?
Primal doesn’t even read a single event from the relays you added.
Shame
m-relay 🤔
hm, had the idea for an interesting nostr statistics project
it is not 2025 yet there’s still 2 minutes
If you don't know how to get started on #Olas365 challenge, I'll help!
Download Olas from nostr:nprofile1qqs83nn04fezvsu89p8xg7axjwye2u67errat3dx2um725fs7qnrqlgzqtdq0 or Apple TestFlight: https://testflight.apple.com/join/2FMVX2yM
Sign in with your nsec. (Nsecbunker has some issues, at least on Android.)
Post a photo from your New Year's Eve celebration 🎊 🎉 and then post another photo every day for the next year.
Advanced options: You can also add your own Blossom server under settings if you use a specific one. For example, #Haven users can use their own server here.
Wait, wasn’t that the app that leaked people’s locations
there are some things best left not known
Check the profile.
And it says parody.
🙃
Those devices use a subpar SE that cost only 50c or so less than proper ones
Congratulations you violated rule 1 of smart card development
ALL KEYS REMAIN ON DEVICE ONLY nostr:note1j5l75cvwevcvxxtvjnefrxf9lernnhk5vnutsxkye3y69k4l6dqqn5g9pm
Have been working on a lot of things in the last 6 months.
There’s a lot coming 👀