pull down to refresh
@rblb
50,211 sats stacked
stacking since: #352021longest cowboy streak: 8 verified stacker.news contributornpub1klt4m...pcysd4kr0priccardobl
10 sats \ 0 replies \ @rblb 16 Apr \ parent \ on: Nostr Game Engine nostr
Checked it out right now on github, nice project.
For nge i'm building something that can run natively with very low overhead as it will be used in a swap-in replacement for the jMonkeyEngine netcode
It is based on a modified version of the draft nip-100, with an option to automatically fallback to send compressed traffic if the relay advertises itself as turn server and the p2p connection is not possible.
Hey, that's me 🌚.
OpenSats was kind enough to sponsor me through this endeavor.
A proper announcement with demos will happen sometimes next month, in the meantime development is happening quietly here.
It is pretty important to get the network stack right and nimble as overhead builds up pretty quickly in game engines, so the initial development will be pretty boring.
Looks like the 'aha' bit is coordinating/facilitating P2P connections via nostr relays.
That's one of the main things i am excited about. The previous iteration was nostr-rtc.
The idea is to have an hyperswarm-like system, where nostr relays are used instead of the dht for signaling and a subset of webrtc is used instead of udp, so that native apps and web apps can communicate together with a single p2p protocol. I expect this to be pretty cool.
Ok.. i'll try once again:
This entire concept will not work reliably because servers, intermediaries and clients will drop the connection if there is no data transmission for some time. That's what i mean with "not working in real life". You'll have to send keepalive packets and do all the stuff that tcp is already doing for you.
HTTP streaming is to stream data you already have (eg. streaming a video from netflix or the feed from twitch), they are not designed for what is shown in the example, for the things i said earlier.
If you don't believe me or don't get it, I think you should look into why websockets were created in the first place.
Can’t you just retry with HTTP if the stream is dropped? And you don’t have to do that with websockets?
No, you don't have to do that with websockets, because you rely on the tcp stack to do that. HTTP/2 connections are also tcp, of course, but they have an idle timeout, after which the socket is forcefully closed.
You can reopen the http stream, sure, but you will be dealing with a dirty close.
You don’t have to parse the app-specific messages you send over websockets?
I am not talking about parsing the content of the message, but extracting the message from the stream.
Websocket are message based, if you use a raw http stream you'll have to figure out where the message starts and where it ends.
Is this not built into HTTP/2?
Not if you abuse the protocol like that, because your application will pipe all the data through a single stream and wait for responses, you'll have implement a queue for writers, and a callback mechanism of some sort, if you want it to be efficient.
To make this work in real life you need to
- periodically send keepalive messages to avoid the server dropping the stream if it stays idle too much
- implement message parsing
- implement multiplexing
so you end up with a shitty non standard websocket implementation.
I'm writing an high performance and memory efficient nostr library that will be at the core of my next (semi announced) project 🗿.
policing what people can do with their private property seems like a good and very europeanunionist idea, much better than supporting or bearing the cost of building ads free alternatives or just installing an adblocker /s
sorted by my personal preference:
- Trine
- unrailed
- ibb & obb
- out of space
- moving out
- biped
- unravel two
The (encrypted) sync feature, pocket and ai chatbot run on mozilla servers, also they do collect statistics if you enable "Firefox Data Collection".
Likely there is some interaction also for extension updates and rtc signaling, maybe more.
US tax payers should not pay for it.
Mozilla could just go back doing an excellent job, like in the past, and collect donations from the community, instead of pushing propaganda and choices that everyone hate to get funded by USAID. Or they could show privacy preserving ads in new tabs, like in brave.
There are several options better than selling user data or pushing propaganda.
By their own admission, they have always been a Bitcoin company; we just didn't know. https://x.com/ProtonWallet/status/1866866021413556294