Subnostr

Hi, All.

I recently developed a WebSocket server.

I plan to embed this WebSocket server into a future Nostr relay that I will develop, with enhanced documentation, comments, and testing.

https://github.com/Hakkadaikon/websocket/tree/main

By the way, there's something I've been thinking about lately.

Nostr runs on top of WebSockets, And WebSockets run on top of TCP/IP.

In the case of TCP/IP, data cannot be received in bulk using a system call, so we believe there is a problem in that it is difficult to improve performance beyond a certain level.

I believe that if Nostr were run over a UDP protocol such as WebTransport, RUDP, etc..., Nostr relay could operate even faster.

For a plain Nostr relay delivering text events, probably won't need to go this far.

However, I think this Nostr relay can be useful for delivering volatile, streaming, real-time data.

In the future, I plan to create a PoC that runs Nostr on the UDP protocol.

What do you think?

Comments, positive or negative, are welcome.

#nostr #grownostr

Reply to this note

Please Login to reply.

Discussion

Finrod Felagund 1y ago

I’m interested to see such a PoC. Do you have an idea when you’ll start working on it ?

発火大根 hakkadaikon🎤 1y ago

Hi!

Thanks for your reply.

I'm going to look into the WebTransport and RUDP specifications in more detail and start development soon.

Finrod Felagund 11mo ago

I look forward to that.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

our nostr:npub1qdjn8j4gwgmkj3k5un775nq6q3q7mguv5tvajstmkdsqdja2havq03fqm7 and nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn are both familiar with C

my relay #realy is here https://realy.lol it's written in #golang because it's the best language, that repository is a composite of forks of fiatjaf's go-nostr and relayer projects that have been heavily rewritten, most of the JSON handling is done with custom, super fast hand written codecs, i took his eventstore - the badger version, which he hates, and made it super sleek, it also has a garbage collector so you can control how much storage it uses and i just got done adding full support of expiration tags just today so it can be used with events that you mean to be deleted... and yes it also properly deletes events, as requested, if you made them, and i'm pretty sure between the custom JSON codec and the badger k/v store it could be one of the fastest relays there is

as for these other things, media and streaming and such, it's go, it's not hard to plug things in like this i just have been focused on getting the base right

also, #welcome to #nostr, fellow server/back-end/systems programmer

発火大根 hakkadaikon🎤 1y ago

Hi!

So you're also developing a relay.

I've already starred your product on Github.

thank you !

il_lost_ 1y ago

I think two servers can decide which protocol to use to pass data to each other, I think Semisol's proposal (1671) goes in that direction. The iroh thing seems to have good participation here two other things I've seen recently

I saw this projects

https://github.com/duozhutuan/NostrBridge maybe nostr:nprofile1qqs06ph4g27xcp4rnzqczr0fzlnvt5nhm763dzd9dzkhk7j534k4fngpp4mhxue69uhkummn9ekx7mqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3wamnwvaz7tmwdaehgu3ww33xz6fwd4jn5dfexgq3camnwvaz7tmwdaehgu3dxqcju7tpdd5ksmmwdejjucm0d5q32amnwvaz7tmjv4kxz7fwd4hhxarj9ec82csppamhxue69uhkummnw3ezumt0d5w4z029

can say more

also pocket relay https://github.com/StevenDay83/pocket

発火大根 hakkadaikon🎤 1y ago

Thank you !!!!!

I'll check out nips #1671 and your other products!

https://github.com/nostr-protocol/nips/pull/1671

MichaelJ 1y ago

WebSocket is firmly established as the communication protocol for Nostr, at this point, and to break from that entirely would be to break compatibility with the larger network.

That said, I don't see a problem with relays offering different transport options for the same events. If every relay offers WebSocket, some may additionally offer protocol extensions to alternately use WebTransport or HTTP, for instance.

A client should be able to connect to any relay using WebSocket, but specialized relays offering additional communication protocol options may have a place.

発火大根 hakkadaikon🎤 1y ago

Thank you!

I will try to verify whether I can successfully implement the RUDP or WebTransport protocol stack as an extension protocol in the WebSocket server.

I will also check the nips issue (1671).

MichaelJ 1y ago

I don't think it should be an extension _to_ WebSocket, just that relays need some way of advertising "I can use RUDP!" or "I can use WebTransport!" so clients know which relays they can try to connect to using those protocols.

Definitely look into the NIP-91 proposal, like you mentioned; it may be a good fit for this.

semisol 1y ago

WebTransport would be the best, as there is browser support, and QUIC does most of the hard lifting

ChipTuner 1y ago

In terms of nostr, I think I would consider transport optimizations as a microoptimization. Many high speed data transfer protocols are run via TCP and don't consdier it to be enough of an issue to build a UDP enabled application layer.

However the other foundational principal for nostr is that it's primary focus is simplicity and availability with existing technology. Most applications/frameworks can more easily have access to websockets effectively giving them access to the transport with the help of http.

However I'm with nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn relays that have the option to support or upgrade connections for clients that can receive them is a great direction to head in, but were still early, nostr needs working and tested software not optimizations at this stage.