Yeah. I'll gladly rename it so there's less confusion. The way I handled the NIP is that it is still primarily Nostr, but I specified a deterministic way to encode the Nostr event into MeshCore packet and back - in a way that the Nostr event is fully reconstructed, including the valid signature. Basically keep only the most precise geohash (although we include less precise for easy queriability), etc. The goal is to be able to pack everything into as small packet as possible, but also be able to unwrap it back into original Nostr event. Do you have a specification of events that you use? We might do it the other way around - if it is possible, we can use your event type and I can devise a way to compress it into meshcore packets. And I'll change my apps to use your event type. My app has no users, it's a demo at this point, so I'm totally OK with continuing with yours, if we can keep this property and extend it to MeshCore. My app is also primary Nostr, MeshCore is not yet implemented (I need a bit of work on MeshCore side as well, so it is user friendly - currently you can connect only one MeshCore app to a node, so we need a MeshCore app that can take and send events from other apps, so users don't have to choose "now I'm driving, I am opening app X, now I want to chat, I am opening app Y"). But I'll solve that part easily.

Replies (1)

I'd definitely prefer having a single shared Nostr event format rather than maintaining two separate protocols, especially if we can preserve the original event ID and signature when converting to and from MeshCore packets. I think the best next step is for me to put together a proper specification of the events Roadstr currently uses, along with some real signed examples, so you can take a look and see how much of it could fit into a single MeshCore packet. If some of our event fields are too flexible to compress deterministically, we could also consider a compact, MeshCore-compatible subset without sacrificing the full functionality of regular Nostr relay events. And I really like your idea of a shared MeshCore companion service! Having multiple apps communicate through the same radio node instead of competing for the connection makes much more sense. So yeah, I'm happy to go in that direction. Roadstr can keep handling the navigation and reporting side, while remaining open to MeshCore as an additional transport layer.
↑