Hi all!
I went on a bit of a coding spree, and experiment mode this weekend, and crashed my way through the development of a completely command line based super sparse/simple chat system, with a single chat room.
I’ve tested it over live networks/networking, and it works!
I’d love to have other people take a look at it to get ideas, and/or to try it. I tried to make it really easy to try out. You can even try it in two separate terminals if no one else is online or available.
That sounds so cool. Is there a way for a non dev to try it out? I know how to work with a command line in Linux. I do not understand the commands or any coding.
thanks for the shout out. it’s not that difficult to access it through the command line if you’re that enthused, but would you just need really detailed instructions?
looks like you both got it working.
I myself am curious about where the slowness is coming in. I’d like to benchmark some of the function calls and check how long in milliseconds they take. Based on its current implementation, the sender will know roughly how long it is taking the receiver to receive it, because it is waiting for the receiver(s) to confirm receiving it before letting you send the next one. I don’t think this is ideal.
It naively tries to send a notification/message to everyone who has registered into the DHT/app, so that could get burdensome if the user scale grew. It might be better if people, when they came online (or went offline) notified the DHT and it checked the DHT for only the supposely “online” agents and tried to send messages only to them, rather than to any agent that has shown up in the DHT at any time.
these are ways I might go about speeding it up. First have to check where the bottle neck is. I read from Holo team that they are seeing times a little bit slower than they had expected in current real-world testing they’re doing, and are just starting to unpack that as well. Any bottlenecks they clear up would benefit this and show up here.
@dcts you mentioned ‘how this chat works’. A few details are above… beyond that… ok, here’s a quick one:
The Holochain DNA quite simply:
Creates a “Path” (a known DHT address) to link Agent players off of
Creates a “Path” to link Messages off of
When a new player joins, init automatically links their agent address off the Agent Path
Also, an unrestricted capability grant to call the “receive_message” function is committed, on “init”, so that other agents can “signal” them via “call_remote”
When ‘send_message’ zome function is called, it commits an entry, and links it off of the Messages Path, it also fetches all known agents it knows of off the Agents Path, and iterates through them, calling “call_remote” into “receive_message” on all the remote agents. The agents which are online will receive it. I think this is where the slowness is coming in.
When “receive_message” is called, it also calls “emit_signal” and forwards the message through to any listeners to app signals through the conductor
I set up a way to attach a signal listener to the conductor, via Rust itself, which listens for those Message signals, and prints them to the CLI.
There is also the elements that the conductor manages which is just … on load, it looks for this “./databases” path relative to where the command was run. If it finds evidence of an existing installation, then it will simply resume. Otherwise, it will generate an identity, and install the DNA to the conductor. Holochain library automatically manages remembering running apps and identities via the persisted stores (cells, conductor, p2p, etc)
Any users of it would have to coordinate with someone else using it to be online at the same time in order to see the messages that other people have sent. So if one of you pings me I can pop online, and see if we that coordination.
I could be online later today to coordinate with you. I’ll set up a reminder for myself to ping you here in about six or seven hours when you’re likely to be online.
But I have some questions/inputs:
