Replying to Avatar brito

On https://geogram.info you find the ongoing development of an app for exchanging messages using BLE, radio waves or the internet.

The development started about an year ago on ESP32 and Android devices and after many experiences it is finally becoming available. Small previews were published earlier like this example: https://primal.net/e/nevent1qqswe3t8xlr3ted45hks7wj2mz65q0njh4pwfns6s57ly4ahapnellg0vujn7

NOSTR is used by default for authenticating messages and identities, will incrementally grow to become a fully compatible relay.

I'm publishing first the web app (my apologies are not yet fully working) and then you should see the Android version following soon after. The ESP32 version (fixed station) comes last once the format/protocol is settled because development there is the hardest.

If you'd like to test and provide early feedback, just head out to the site and try things. Around October the site should be fully running.

Coming back to this again -

We're going to need a better version of the nostr protocol before we can really develop much of a radio network on it

The current version is javascript-centric and English-centric and wastes a lot of data in the encoding to stop computers from needing to translate it to be readable by noobs

It's cripplingly wasteful and very stupid in an internet context but would be even more crippling in a p2p radio context

More than & before p2p nostr radio networks develop, it seems like we first need new nostr encoding standards that don't do stuff like waste multiple bytes to encode a boolean value by insisting on giving it a special name transmitted with every message

Reply to this note

Please Login to reply.

Discussion

Yeah, I just don't use the NOSTR format for radio communication and won't be waiting for a better format to come around.

In the meanwhile just exchange very small packets of information and that's how it goes. It is already difficult enough to exchange signatures when the average communication message can't go above 16 letters on bluetooth and about 50 characters in other radio formats.

I don't have a good answer yet but will continue experimenting until reaching somewhere that is shorter and at the same time keeps all the good stuff from basic json notes.

Do you have time to explain a little more? What is nostr used for vs what the radio part does?

For example on BLE communication the long messages are broken into pieces. The first piece is the header which indicates how many pieces to expect (2 characters), a specific identifier for that message (2 characters), the last 4 characters of the verification signature and the call sign for the destination (6 characters).

This gives enough information to:

1) permit knowing when pieces are missing (many are lost during transmission and need to requested again)

2) to know if they are targetted to the device listening (otherwise ignore)

3) in the end to verify if the last 4 characters of the verification result are matching with the full verification result based on the NPUB associated to that callsign.

For this to work, at every minute or so, all the devices advertise their callsigns and NPUB on bluetooth broadcasts to whomever is listening.

On the other radio waves is similar, albeit adapted to the conditions of each frequency or limitations of the radio protocol.

There are flaws on this approach. For example, someone can spoof a callsign and present their own NPUB but this is meant for local usage without internet available. When there is internet, it is possible for someone to register a callsign with an NPUB on the central geogram server, which then periodically distributes an offline list of NPUB mapped to callsigns.

For example, if the radio wave is Wi-Fi like the newer Wi-Fi Halow or ESPNOW that can reach between 1 and 10 km then there is no need for these procedures, just send the normal NOSTR json files as you'd do on internet because they are fast enough for that kind of data bandwidth.

I think I kinda get it

What about decentralizing the central geogram server?