prototype-cjdns-pi
prototype-cjdns-pi copied to clipboard
tomeshnet
Add Cabal chat
This looks very suitable as a service on mesh. It's p2p not federated: https://cabal-club.github.io
Looks interesting, and the desktop ui looks great which is nice, even though we can't put that on the pi, I think having a good desktop ui will come in handy. It does use dat though, which different then IPFS, but similar enough that we might want to talk about whether it makes sense to have both. I personally would also like to wait until there is some documentation on how it works beyond just installing it. Now that you mention live p2p chatting, I love the idea, so here are some other ones I know about:
I like the idea of having chatting, and so I think it might be worth comparing these three, and any others we can dig up.
There's also a lo-fi terminal client that runs on the pi.
How it works: it uses discovery-swarm to find peers on the local network as well as via the bittorrent dht. Each cabal has a shared symmetric key that identifies it and encrypts/decrypts traffic. That key (or its hash) is also used for discovery on the aforementioned networks. Each peer maintains a signed append-only log of their messages, and aggregates the logs of the other cabal chat participants to form message history for each channel in the cabal.
Thanks so much @noffle! I did see the terminal client, I forgot to mention it but yeah it's awesome to see both a desktop and terminal client, it'll be great for testing and regular use. And thanks for the explanation, it makes things much more clear. I was being stupid about thinking dat was involved, it seems. It looks nicer than the two ones I linked, this gets a thumbs up from me @benhylau. I would like work on adding this and make a pr for it, although I'd like to hear from @darkdrgn2k first.
I would like work on adding this and make a pr for it, although I'd like to hear from @darkdrgn2k first.
Sounds like a nice addition if you want to work on it.
@noffle I remember why I thought it was about dat now. The irc channel mentioned on the website is #dat. Why is that? Also, I have some more questions but don't want to clog this ticket. Is there anywhere we can talk more? Wire, matrix, a different github ticket?
Some information I've discovered about cabal for tomesh members to know:
It's having some issues right now, as outlined here. Once those are resolved, the bigger issues is it relies on the bittorrent-dht which doesn't support IPv6. There's a guy working on it, as they say here, and I've asked him when it will be ready. In the meantime we would need to do what is being done by us for SSB, and what is being considered for IPFS: create and send fake mDNS packets to CJDNS peers, because cabal peering works fine over LAN using mDNS. I could use nodeinfo to know whether peers are running cabal or not. I'd also like to get @noffle's opinion on how bridging IPv6 and IPv4 would work, because whether we use IPv6 bittorrent or mDNS, chatting would be restricted to that network. What happens if a computer is on both a closed mesh and the Internet? Will it gossip the messages and allow acccess to that cabal on both networks?
create and send fake mDNS packets to CJDNS peers, because cabal peering works fine over LAN using mDNS
I would put that on the back burner and worry about all the other problems first. There may be some movement on this in early 2019 from a few differt angles.
As mentioned in chat, I think I can conclude that cabal doesn't make sense to add right now. Until bittorrent-dht supports IPv6 or there are other workarounds from a CJDNS standpoint, I won't be implementing this. I will look at other p2p chatting applications, and keep up with bittorrent-dht development.
@makeworld-the-better-one You were right about dat: cabal uses several low-level modules from the dat project's stack, even if we don't use "dat" (the software) outright.
Re IPv6, dat has been developing a new DHT called hyperswarm, which, lacking backwards compat requirements, might be in a good position to support IPv6 from the start. I filed an issue: https://github.com/hyperswarm/dht/issues/1
We could also replace dht and lan discovery with something completely different that makes more sense for your network layout, like (just spitballing here as an example) using your cjdns config details to find cabal peers. Cabal is modular enough that, if you can get it peer {ip,port}s and get a duplex stream between you and them, you can exchange chat messages.
We could also replace dht and lan discovery with something completely different that makes more sense for your network layout
Not sure how Cabal works but SSB and IPFS need some sort of hash from the remote server to initiate a chat. You cant just connect to a port and start peering.
SSB uses an IPv4 udp broadcast to publish that hash to listening SSB instances. (There are active projects to get that working on IPv6 Multicast). The instances that receive the packet then initiate a connection back to the originating SSB instance with the hash provided.
That would be the ideal model. We currently can craft the ipv6 multi cast packet as a uni cast packet to each peered peer (since we know the ipv6 of all peers peered to us)
But that's future problem. First lets get Cabal working as it is (on ipv4) and we can worry about the rest as solutions come out of the wood work.
@noffle I saw the post about hyperswarm, it looks good, thanks for making the issue. It might be nice to see cabal transition to that eventually, but for now what you suggests makes sense to me. Ideally LAN peering still happens automatically, but there's also some API that allows for manual IP and port peering. This way we don't have to create mDNS packets like @darkdrgn2k mentioned. Does cabal have a way to do this now? I agree with @darkdrgn2k though that this is future talk, for after cabal-core issue 17 gets solved.
@makeworld not implemented currently, but I don't think it'd be hard to expose
@noffle Exposing that would be much appreciated. Do you mind posting here whenever you're able to do it?
Having a chat with @noffle that is probably interesting to more people, copying here:
noffle: . . . once things are more stable I'd be interested in exploring how cabal might be deployed over cjdns. It uses a DHT for routing, right? Can you store arbitrary topics in its DHT too? I wonder if we could use that for discovery.
benhylau: I don't think you can store stuff on the cjdns DHT and routing also changed to supernode as of a couple versions ago. So DHT is like a legacy cjdns feature now :( we still use it in Toronto Mesh. To make things work over cjdns/yggdrasil I think you only need to make sure Cabal is IPv6 compatible. What do you mean by discovery? Like for users to list some public rooms, or for Cabal nodes to peer with each other? For the latter I think it is related to this discussion: https://github.com/tomeshnet/prototype-cjdns-pi/issues/177
noffle: It looks like utp-native is IPv4 only right now, which is what discovery-swarm uses. But cabal could also peer using regular tcp connections, which supports IPv6 in node. Re discovery, I meant the act of finding other peers on the network who are interested in specific cabal. Pinging only your immediate cjdns peers might not be widely enough to find enough cabal peers on the network to propagate your messages. (each cabal has its own swarm; it's not like some protocols where ALL users swarm regardless of the dataset they're interested in)
benhylau: Ahhh so you actually need to discover an IP that is also on your specific cabal address, not just running cabal in general. Let me see if I understand the problem correctly: Node A and Node B are one a network with flat IPv6 addresses. They don't know each other's IP address but are both swarming cabal://00794539a8ce6bed76e40b9d259666303d39271da66140282bfbce76fd9a4434 so you need them to peer. How do they mutually discover a path to each other? Your thinking is: If we can tag metadata such as the cabal ID to the cjdns DHT, this information can piggy-back off its path-finding mechanism. Am I on the right path of thinking about this?
noffle: correct on all points! Right now in ipv4-land, we use either: multicast on the local network with the cabal id (or a hash of it), to find others interested in the cabal join a global dht and ask for others interested in the same topic (hash of the cabal id) Since the cabal id is just a key, it doesn't give any hints as to how to find peers' IPs, on its own.
Hmmm. I see the need for a global DHT, I guess we have two choices: Wait for bittorrent-dht to support IPv6, or possibly implement our own tomesh node DHT for cabal, and I'm sure we could find other uses for it. This is because cjdns DHT is obviously not an option, I've inquired about the yggdrasil DHT on their chat. With either of these choices there are issues with DHT fragmenting, either between IPv4 and IPv6 in the former option, or with multiple isolated meshes in the latter.
In the meantime, connections can happen between direct peers for testing at least, once that gets implemented by the cabal team.
Can we use libp2p, cabal ID as node ID, and let libp2p take care of discovery via DHT or other means?
The discovery cabal uses comes from a different module: https://github.com/maxogden/discovery-channel
For them to switch to a different dht they might have to do a lot of work. So I made an issue in that repo about IPv6 support, suggesting using the libp2p dht as an alternative.
See web UI:
- https://message.land
- https://twitter.com/joeahand/status/1072180050466824193