Sure, however taking stuff that works and porting it is ‘developing’ apps
In that vein, using a direct connect chat app which just needs an autonomi way to resolve clients, is probably a good start.
Ofc, it depends on how much privacy is needed, vs just having decentralisation, etc.
absolutely! we should have a live chat that just communicates contact info via autonomi
next level is any kind of application exchanging messages (e.g. a DEX on autonomi)
Also take a look at Trystero linked in my original post. It has an option that uses libp2p (on IPFS), so may be easily modified to work on Autonomi.
Just to throw in - if we want one that just works - there is the open source tox protocol. Many chat apps built using it. I use QTox for my desktop. It’s simple with a few knobs once you create an ID. It is fully decentralized using DHT.
QTox:
Tox protocol isn’t libp2p and uses tcp exclusively AFAIK. So any fork of any of the apps to run on would have to be rebuilt for libp2p.
Why is it necessary though? I think it’s more important that we just have a solid working app bundled with One’s network id could be created on setting up your account, and then stored in a transaction data type that points to the users xor address or some such … then everyone can find anyone on the chat linked to that xor address.
I recommend people give Qtox a try - it’s a solid desktop app that I use for my daily.
QTox is no longer maintained though - but they are seeking maintainers with C++ skills - so could be an opportunity for an dev?
Regardless of which tox app you use, you can connect with anyone using the tox protocol, so already has a built-in base of people using it.
My tox id: 7DF227AA4B55BA69159531C517F16EDF491FE66987FE2F82100F66FF4D3C537D8B7F32D82006
QTox is in the debian repo as well - so easy peasy. but here is their download site for those using windblows: https://qtox.github.io/
There are binaries for many distros as well as images and flatpak –
Also there are multiple Android tox apps in the play store - if someone wants to try them. All tox apps connect together.
Anyway, just my two bits.
Before delving much further into integrating existing chat apps with Autonomi, I realize I would need to understand Autonomi’s specific requirements for peer discovery, connection, etc.
Playing around with registers as was done in the past. I tried the following:
ant register create --public test_chat Hi
Register created at address: 9f0e6f28c7768b16a4d5559793f46caf8bb6ed5cbe29fe9372f6e13df2e8411984604b15ae9c34639e58f51f0e3d5e53e71eecbd2939eb875f062c15cd2b80c90a63efd148c9d6d7056b1e3520010b05
With name: test_chat
And initial value: [Hi]
Total cost: 3 AttoTokens
(I think the charge was for naming it, but I’m not certain.)
Edit: Verified, the charge was for naming the register.
You can try writing to this register using the following:
ant register edit 9f0e6f28c7768b16a4d5559793f46caf8bb6ed5cbe29fe9372f6e13df2e8411984604b15ae9c34639e58f51f0e3d5e53e71eecbd2939eb875f062c15cd2b80c90a63efd148c9d6d7056b1e3520010b05 <value>
and any other participant can then get your message using
ant register get 9f0e6f28c7768b16a4d5559793f46caf8bb6ed5cbe29fe9372f6e13df2e8411984604b15ae9c34639e58f51f0e3d5e53e71eecbd2939eb875f062c15cd2b80c90a63efd148c9d6d7056b1e3520010b05
Assuming that works, I could envision a rudimentary script to listen for changes to a register and report the “new message.”
But there is not a way (e.g. naming mechanism) to identify the sender as far as I can tell (unless the sender includes their name in the message). Anyway, just playing around with that… if anyone wants to try it, let us know that you changed it, and we can check it out!
Good digging! Yes, registers could be used, but they are being deprecated. I have also had no joy changing the values using the CLI either. The CLI also doesn’t show the change history, which would be key for allowing multiple people to join a chat room easily.
There is a new API feature under development, which has been called Transactions and more recently Linked List. We will have to see what is baked in oven, but it sounds like a good data structure for working with mutable data.
Fwiw, I use registers in sn_httpd for DNS lookups, but without edit from CLI, it’s a bit broken/pointless atm.
It’s good to get a feel of what is possible now though and how it fits into the new API. The CLI certainly needs some love to surface those new API features too, but it’s getting there (e.g. archives uploads are nice, at least when they succeed! ).
Yes, just a little chomping at the bit and exploring for now .
I’m curious what you mean by “without edit,” as I was able to edit the value of the register in the CLI using ant register edit.
Yes, python, rust and nodejs (typescript) are all what I am working on for the client. They will all be there.
like this?
Logging to directory: "/home/willie/.local/share/autonomi/client/logs/log_2025-01-05_07-39-30"
🔗 Connected to the Network Getting register at address: 9f0e6f28c7768b16a4d5559793f46caf8bb6ed5cbe29fe9372f6e13df2e8411984604b15ae9c34639e58f51f0e3d5e53e71eecbd2939eb875f062c15cd2b80c90a63efd148c9d6d7056b1e3520010b05
Found register at address: 9f0e6f28c7768b16a4d5559793f46caf8bb6ed5cbe29fe9372f6e13df2e8411984604b15ae9c34639e58f51f0e3d5e53e71eecbd2939eb875f062c15cd2b80c90a63efd148c9d6d7056b1e3520010b05
Updating register with new value: Hiya Helen -- Best Regards Southside
✅ Successfully updated register
With value: [Hiya Helen -- Best Regards Southside]
And I dunno if this is a reply or a weird truncation of my original
willie@gagarin:~$ ant register get 9f0e6f28c7768b16a4d5559793f46caf8bb6ed5cbe29fe9372f6e13df2e8411984604b15ae9c34639e58f51f0e3d5e53e71eecbd2939eb875f062c15cd2b80c90a63efd148c9d6d7056b1e3520010b05
Logging to directory: "/home/willie/.local/share/autonomi/client/logs/log_2025-01-05_15-04-16"
🔗 Connected to the Network Getting register at address: 9f0e6f28c7768b16a4d5559793f46caf8bb6ed5cbe29fe9372f6e13df2e8411984604b15ae9c34639e58f51f0e3d5e53e71eecbd2939eb875f062c15cd2b80c90a63efd148c9d6d7056b1e3520010b05
✅ Register found at address: 9f0e6f28c7768b16a4d5559793f46caf8bb6ed5cbe29fe9372f6e13df2e8411984604b15ae9c34639e58f51f0e3d5e53e71eecbd2939eb875f062c15cd2b80c90a63efd148c9d6d7056b1e3520010b05
With value: ["Hi"]
We moved again and they are now called GraphEntry
as they allow forward and backward searching through a graph structure. @Anselme was instrumental in that one.
So we have pointers that can point to any data type (including other pointers) and then Graphs, so we can have full history of filesystems etc. and pointers to current. This will give apps a chance to be well behaved, i.e. use pointers for current values but provide the Graph to go back in time.
Yes, interesting that it gave you my original message back when you issued a “get”… I just tried it and also got “Hi,” so it seems that, as @Traktion mentioned, register edits aren’t working, even though they appear to at first.
Unfortunately, that means you missed my important message: “Congratulations! You just won the lottery!” Too bad…
Damned shame, that…
It says it changes the value, but when I query it, i always get the original. Same for you? I tried a bunch of times with no joy.
It used to work intermittently recently (maybe last net?), but seems fully broken now for me.
Yes, Southside tried to read a message but it only retained the original value… Same for me.
Possibly a naive question…
… I did some tests a few weeks back with udp hole punching…
And it wasn’t an issue at all to establish a connection tbh… As long as I knew public ip and port that would be used to enter the Internet I was able to talk from local laptop behind router (no port forwarding in router) to a cloud machine with active firewall (and no incoming exception for the communication) even when it was quiet for some seconds… So the ‘same time point’ for home punching is a pretty rough thing and a couple of seconds difference are not an issue… You just need to make sure no messages get lost… The initial might…
Which would mean we just need to know which public ip and which outgoing port is being used…? Does anybody know of simple services that tell you from which ip/port the communication is arriving at them…? Ideally a node might have the ability to tell this…? (then 2 communication partners just would need to put their rendezvous info and 1 of a couple of time points into a data file stored on autonomi and they could contact each other pretty easily a bit later.)