Feature Proposal 5: Implementing Nostr in Grin++/grin-wallet/IronBelly
What is Nostr?
For those who missed it, Nostr is a decentralized network protocol for a distributed social networking system. Posts are resistant to censorship and are cryptographically validated. Similar to Tor, messages can be sent via multiple hops in routing to reach the recipient. So Nostr works as a Mesh network similar to Tor.
How does Nostr compare to Tor/onion-routing?
Currently, interaction between wallets goes by default via the Tor network and if the receiver is offline, a slate-pack message is served to the user to send via any other method such as copy paste in a web-browser, email, Signal etc. Some users perceive the need to use these channels as a disadvantage. The biggest advantage of Nostr is that A) Nostr is a social network protocol and therefore allows chatting between users and b) Nostr serves as a message buffer/bulletin board. Meaning that if the receiving wallet is offline, the intermediate nodes will store message (but there is catch). To avoid spam though, relaying might cost something, meaning you might have to pay in BTC/LTC/Monero or possibly Grin.
Nostr basically can serve as a bulleting board. This has been discussed many times, see here the best link on Bulletin Board Discussion. There is another disadvantage to Nostr, that is metadata on Nostr is not encrypted, meaning you can see which nodes send messages to each other. So some work needs to be done, such as empheral keys/ID’s, randomizing size of messages or perhaps other solutions to protect users privacy.
Overall Nostr is an interesting, distributed messaging solution that is still relatively novel but can resolved the need for Grin wallets to be offline. Any non-distributed messaging system like Signal, Telegram or WhatsApp can also relay transaction slates but these solutions are more centralized and require you to leek your phone number, which is undesirable.
What we need from you?
We need your input, discussion. The purpose of these and all other Funding Proposals is to provide opportunity to discuss feature proposals and only move to any funding request or bounty if there is sufficient interest from the community and if there are valid arguments to move to a funding request.
My personal opinion on this funding proposal.
Yes, Nostr is interesting to implement in the future but there are still quite some issues to solve. Waiting a bit might therefore be strategic and cost saving.
Secondly, I do question if this needs to be funded from any official funds or can simple be done as part of a hobby project. If this feature implementation will be funded, I do think it should be modest and only funded when BTC is > 30k$
This too feels like a good bounty. CC does not need to be funding a dev salary for this, but a small grin bounty would serve as a nice prize for anyone working on such a project
@Trinitron Can you elaborate? Do you mean we do not need to provide means of transport next to Tor since users can already use slatepacks to send via any other medium?
This project is big as we need to setup relay also and it should be paid to avoid spamming. As for me I want to see this relay accepting Grin as payment.
Nostr is experimental thing. As transport we can use even IPFS. Relying to 3rd party TOR only is big mistake. Let’s bring choice to user.
I mean that I think transport is unnecessary, including Tor.
Tradeogre uses slatepacks, grinmint uses slatepacks, when I want to send grin to another user I PM them a slatepack.
I don’t think Tor/transport was ever necessary and it only ever was taken up by a few mining pools I think. I think slatepacks are a fun part of Grin to be embraced and celebrated rather than worked around.
Think about automation, communication between machines. Transport can be necessary to automate slatepack sending, like at internet shop instead of copying paste, simple press button and other side will give you response, eveything under the hood, all you need is to have your device to be online or offline if we are talking about some persistence like IPFS.
I think those are far away dreams. Tradeogre’s interfaces shows that a checkout interface with slatepacks is already possible.
By the time we get to someone desiring a faster checkout interface years from now the merchants can fund that effort. We don’t even know if nostr will still be around by then.
Tor transport was built and essentially not adopted and went out of style, I expect the same outcome if nostr transport is built now.
Problem with Tor on Grin is stability and non-availability at every country, http transport worked perfectly, but its not private, so devs decided to cancel it at default wallet I guess. Interesting why not I2P? Niffler is still using http, I will add it too just after raw slatepacks, Tor is not priority
Merchants just need SDK for their shops to be integrated for 2 clicks, same for users to avoid using VPN. @noobvie already said he will fund this work a bit.
All we need is developers. As usually
P.S.
There is big list of application layer protocols with adoption (even ZCash is in list, but not Grin/MimbleWimble):
Nostr also has this problem though. Many countries have already banned Nostr and related technologies. Nostr is not an improvement for global availability.
You know what is available everywhere? Slatepacks.
http as protocol, slatepacks is data you are sending through, tomorrow your favorite messenger can be banned too.
Question is how we are sending them. Another cool option to adopt is SOUND. You can call your friend at phone and play him this sound. And he will play you as response. Much easier than reading every char inside slate message. Discussed here.
Not sure if my idea is off-topic but has anyone thought about embedding messaging functions like Wechat into Grin wallet? It’s also a way to spread Grin better
How do they ban Nostr relays? It’s just a server with web sockets, right? Nostr is basically thousands of networks. There isn’t one single Nostr network, technically speaking.
Exactly. Protocols get banned. Servers serving a protocol get blocked. But data is nearly impossible to block. If I have a slatepack, i’m not bound to any one protocol or messenger. I can post my slatepacks to nostr if I want. But I don’t have to. I can also send my slates via sms, email, or usb drive strapped to a carrier pidgeon.
You say TOR is bad because the protocol gets blocked in some places. I say Nostr protocol also gets blocked in some places. But nowhere blocks sms. Nowhere blocks email. Nowhere blocks slatepacks.
By blocking connections to the ip addresses of known relays. New relays can be created, but they get blocked. Its a cat and mouse game.
Don’t get me wrong. I think a Nostr wallet would be cool. I just don’t think it should go into the Grin reference wallet, and I don’t think it warrants more than a small bounty. Not some exorbitant funding request from CC.
I’ll put my thoughts more concretely: I do not think CC should sponsor projects that have recurring costs like running a relay. If someone wants to build a wallet that needs a Nostr relay, then they should figure out a revenue model to pay for that relay.
I had the same criticism of the “Blockstream Jade” hardware wallet. It would be a cool wallet for Grin, but it requires a server. Someone other than CC would need to pay that server bill.
In general, the Grin ecosystem doesn’t need tools with excessive dependencies. Grin needs simple tools with minimal dependencies. I consider that a guiding principle when thinking if CC should fund a project.
[Edit] there might be a business opportunity here for any enterprising individuals. Blockstream Jade wallet for grin AND Nostr wallet both would have to be a paid service (to pay server costs) and both features seem desired by the community. Maybe someone creates a business around providing a Jade + Nostr wallet for the community. A small service fee from users would go a long way, and I think several users here would enjoy one or both services.
@AceKaplin Regarding the Jade hardware wallet, I agree that it is best not to link it to a server. Basically I propose to only use the hardware for an air-gapped wallet. Perhaps in the future we could add an option for a a 2 out of 2 multisig if we have that implemented properly. In that case we could use 1 seed to derive 2 keys, one in you App/phone/desktop wallet and second key on the airgap hardware wallet.
For Nostr, I would not support CC funding any relays or anything else with fixed costs or maintenance (lessons learned from buying miners).
I fully agree. And it’s why I vehemently opposed building out a BBS for Grin.
However, Nostr is about as simple as it gets and it is not only used for Grin or some other coin. So if a wallet had an additional minimal dependency it should be something like that that allows the relays to be configurable by the user. Use any relays you want to, even your own.
My personal opinion on this funding proposal.
