Didn’t this project achieve something similar?
The only difference is that instead of sending an invoice to a static Nostr address, you just send it to a Telegram/Keybase contact.
PS: I recommend a read of The politics of embarrassment by Alex Byrnes.
A bot is different than messenger integration although the API part is probably similar. There is also a new Telegram bot:
Regarding the article on philosophy and science. To me it absurd to derscribe science in any way being linked to left or right politics. Science is (or aims to be) objective truth seeking. Trump is a wannebe dictator, not a truthseeker and as such a natural enemy to science and philosophy which aim to understand the world. In fact he is an enemy to anyone who wants to live in a world of facts, truth, honesty and open communication.
MDK has been getting some good development. Multiple different apps now using it. White Noise
I just realized something about decentralized messaging protocols. If it’s a unique protocol like Nostr, it’s actually fairly trivial to block because each message is structured in a certain way.
It’s a lot harder to block something like Delta Chat that is built on SMTP/IMAP because they’d have to block all email in order to block it.
this is to say, maybe the messaging part of Grin Venmo should be built on chatmail
relay itself is centralized part though, actually if we can sync something like SBBS or IPFS on Beam near node.
Own relay = own node.
If you run your own chatmail relay, you centralize yourself? I don’t understand what you’re saying
I mean its must have to sync own “relay” to have messaging stable, domains can be blocked, ideally to not have DNS address at all, g1 address has perfect use-case here:
https://github.com/markqvist/Reticulum/blob/master/Zen%20of%20Reticulum.md
Delta Chat is releasing the ability to use multiple servers (like Nostr) very soon. But as you said, running your own server is fine too.
I was the one that originally shared Reticulum on this forum. But keep in mind that the creator just basically left the project a couple weeks ago.
Stack ideas for experimentation:
mimblewimble-py
reticulum (just use it over regular internet by default)
textual
sqlite
msgpack
grin_wallet_libwallet
chatmail-rs
egui
rusqlite
serde
tokio
@ardocrat btw check out this new reticulum messenger GitHub - torlando-tech/columba: Native Android messaging app using Bluetooth LE, TCP, or RNode (LoRa) over LXMF and Reticulum · GitHub
Of these ideas I find reticulum the most interesting one. A private messaging app that could support slatepacks through deep linking is always interesting. The bottleneck might be adoption though, not sure how many people actually use Reticulum or messaging Apps that use Reticulum such as Columba. Have you tried it?
The venmo/cash app experience is not a full messaging app.
Reticulum (or chatmail, etc) is only used to
Of course it does sort of create lock-in still in terms of “what about people that don’t use that specific wallet with that specific messaging protocol”.
Ideally, slatepacks would just be sent on ANY messenger app in a URL format so you just have to tap and it auto populates in your wallet for you. I think @ardocrat is exploring this with Universal Links maybe? App Search Programming Guide: Support Universal Links .
MoneroDM https://monerodm.org
Both Monero and Tor use Ed25519 elliptic curve cryptography. A Monero public spend key is mathematically identical to a Tor onion service public key. This means anyone can compute a deterministic Tor onion address directly from any Monero address.
Each MoneroDM instance runs a Tor onion service computed from the wallet’s Monero spend/view keypairs. To send a message, MoneroDM computes the public onion address of the peer from the given Monero address.
This is similar to how the Reticulum founder was saying that you could derive a Grin key from the Reticulum ID.
I think this is roughly what grin does, deriving a .onion address based on the ed25519 key (public key cryptography, e.g. signatures). The only difference is that it is bench32 encoded with ‘grin’ as prefix to turn it into a human readable slatepack address.
When the slatepack address is red by a wallet, it gets decoded to the regular ed25519 public key of the wallet, which according to the documentation can be mapped to an x25519 key (Elliptic Curve Diffie-Hellman (ECDH) key exchange protocol).
Still trying to wrap my had about the exact difference between these two key types, same curve, different representation and use case. Cool cryptography if you ask me. I dig the whole slatepack address derivation method, optional encryption of the slatepacks content and deriving a tor address from the same key. Quite genius.
I’ll share here what the creator of Reticulum said. Good to have it for posterity here I think:
Grin is insanely interesting. When I read your post I was like, oh let me just check this thing out quickly and reply on the discussion, and then went straight down the rabbit hole of their docs. While I still don’t have a complete grasp on the elliptic curve math they use (especially for “collapsing” the transactions into combined kernels), I can definitely say that the system as a whole is completely brilliant. Very, very cool stuff. The slatepack concept really got me thinking. I’ve been dazing around with this on my mind for a couple of days now, and haven’t been able to get it out of my head. For one thing, it would definitely be possible to run the whole Grin transaction building process over Reticulum, even in a very elegant and native way, since the slatepack “sender” and “receivers” can be natively represented as Destinations on a reticulum network (both are really just Curve25519 points). But then it also hit me that we could actually build a very neat transaction+finality system directly on top of Reticulum, by using a combination of concepts from Scrit and Grin, and a few concepts. You could actually do this entirely without a blockchain per-se, having the entire network state represented only as a database of unspent outputs. Such a thing would be very efficient and easy to sync. Just for fun, I tried to design a small, high-level, concept-system around this idea, and I think it actually could work. Or I might have missed a bunch of critical details, and it is all just happy pipe dreams. But I think it is worth exploring some more, and I will definitely do so when I have the time. If anyone is interested, I can try to do a write up of the concept and ideas so far. I would be interested to hear your thoughts. The system I have in mind basically aims at making it possible, maybe even easy, to bootstrap economic activity for a community, while ensuring a high degree of privacy, security and distribution of control. Take note of the word bootstrap here. This needs to work from zero, with very little setup cost (both social and capital), and still provide reliability and security. I think this is very important to be able to set up a transaction/value storage system from scratch where and when you need it. This is not usually possible with existing blockchains, since you need huge capital expenditure to have any semblance of security, i.e., you can fork any chain you like, but you are then completely vulnerable, since someone from that chain can just shift 0.0001% of their hash-power towards your chain and completely control it.
Don’t take my word on this as gospel, since I haven’t read their full implementation. This is just what I believe from my initial understanding. But from what I understand, you could build the entire slatepack message just from the EC point math already in Reticulum, and then send it to some node on the Grin network for finalization. You would of course need to hook into a Grin wallet somehow to get the signing keys for actually building the slatepack message, and I don’t know exactly how, or even if, there is an API for that, but I can’t imagine that it’s not possible. Or you could simply add Reticulum as a transport option to the Grin wallet, and have the wallet itself build the slatepack, only doing it over Reticulum instead of HTTPS or Tor. From what I understand, Grin already has a system in place for supporting multiple transports for building transactions, so maybe this is the best way to go about something like that. When I get more time I am probably going to mess around with it, but for now, my hands are full with all the scheduled work on RNS and the new RNode ecosystem.
Having the ability to bootstrap economic activity and fungibility within an arbitrary domain, from zero and with (virtually) zero cost is a really great tool, that I think could be useful in situations like:
When you need the ability to transact and trade on networks that are not connected to the Internet.
When you want to transact reliably, but completely outside the scrutiny of the outside world, or only with a well-defined group of peers.
Organisation of peer-to-peer loans, debt and repayment.
Allocation of resources, responsibilities, rights, services and similar, within organisations, communities or groups.
Ownership management of any kind of stuff.
When you want complete self-reliance for things that are inherently internal to your community (annoying that you can’t re-allocate fuel or water, because the Internet is unavailable, or some node needs to re-sync a 300GB chain over a slow connection). From a social perspective I also think there is a very important aspect in self-ownership over essential tools and infrastructure. If people of a community know that they are themselves in co-ownership and co-control over essentials like the economic transaction system, it directly makes people feel empowered. This breeds individual responsibility, and also helps create a context of meaning. That is important empowerment to return to a community. It’s a small positive feedback loop you can start. The more of those you can start, the stronger a community becomes. Long-term, having self-sovereign transaction and fungibility layers are an important building block of self-sovereign societies, and a necessary precursor to any kind of communally created order-structure. You put that on an “outsourced” tech layer, and what you are really doing is putting your order-structures into the hands of the owners of that tech layer (exactly as it stands in our world now).
The next while for me will be focused on the remaining missing pieces in the Reticulum ecosystem, but here is to hoping that we might be able to collaborate in some way in the not too distant future. The more I look into Grin, the more I like it. I would love to see the ability to perform slatepack exchanges over Reticulum.
@ardocrat @waynegeorge @renzokuken he briefly describes a sort of alternative crypto currency system inspired by Grin that I think is less about global consensus and more (similar to reticulum itself) about many interconnected networks of currencies. But he also explains how he would connect Grin (as it is today) with Reticulum and says he would love for someone to try it out.
Thanks, this sounds very interesting. I need to look more into what Reticulum is
Good! need to check how to generate address and how its stable at all
Thats some good read here:
The read is interesting but quite wordy since it continuesly elaborates on its design philosophy.
What I like is the resilience of the network, assumption that no-one can be trusted so trust the math. I do wonder a bit about how tracable such a minimal hash based ID system is. The writer gives an example that someone might use and rewrite code to target missiles. The question remains how resistant the network would be against mapping, tracing and using physical or digital missiles to attack a node.
Another thought that came to mind is how good is the network in buffering? E.g. can it retain a copy of a slatepack and for how long? Perhaps the network could serve a bit like a Public Bulletin Board system for users.
For what it’s worth, you can feed that entire text to Claude and it seems to understand perfectly well how the key derivation works. At least helpful for a jumping off point. It actually spun up a whole MVP of sending slatepacks over reticulum with the key derivation lol.
Wallet to wallet communication is simple, idea is to use Reticulum for p2p communication at node to replace Tor later if its more stable and has post-quantum encryption.
