[Question] Can Go interact with remote kameo actors?

[timofdev]

I tried to build a Go server using go-libp2p v0.45.0 and go-libp2p-kad-dht v0.36.0 that could communicate with a Rust client using kameo remote actors. I set up mDNS discovery with the rust-libp2p compatible service name and QUIC transport on both sides. I also initialized Kademlia DHT on the Go side and tried to register an actor name.

The peers can discover each other via mDNS and establish a libp2p connection successfully. However, RemoteActorRef::lookup_all() from the Rust side doesn't find the Go server.

Is it possible to make a Go server compatible with kameo remote actors, or is the remote actor protocol Rust-only by design?

[tqwewe]

There should be no reason I can think of why it wouldn't be possible technically. Though I've never tried anything like this with kameo.

The way the registry works with kameo is it first starts providing under the actors name you choose (here)[https://github.com/tqwewe/kameo/blob/7535935d709d04783f84dc8dc54136b2d39d8c53/src/remote/registry.rs#L330-L336], and then a record is pushed to the Kademlia DHT with the format of {actor_name}:meta:{peer_id} (here).

So to make looks ups work, you'll need to both start providing, and save the "meta" record to Kademlia DHT. In terms of the payload of a record, it is:

[peer_id_length 1 byte]
[actor_sequence_id 8 bytes]
[peer_id n bytes]
[actor_remote_id n bytes]

(See into_bytes())

Nothing about this is standardized and promised as a protocol for kameo currently, but if you wanted to get it work, those are the ingredients you'd need:

• Start providing for the actor name: IpfsDHT.Provide
• Put a record with the meta key explained above: IpfsDHT.PutValue

I'd be happy to try and help further, but I haven't touched Go in a few years.

[timofdev]

Thank you for the previous answer! I made progress - mDNS discovery works and libp2p connection is established. However, I'm hitting a DHT protocol mismatch issue.

When I use go-libp2p-kad-dht (default /ipfs/kad/1.0.0 protocol), the peer is added to my routing table but then immediately removed. It seems kameo uses a different DHT protocol.

Questions:

1. What DHT protocol prefix does kameo use? (e.g., /ipfs/kad/1.0.0 or /kameo/kad/1.0.0 or something else?)
2. Is there a way to configure kameo to use the standard IPFS DHT protocol?

My Go DHT setup:

kadDHT, err := dht.New(ctx, h, dht.Mode(dht.ModeServer))

[tqwewe]

The DHT protocol kameo uses is /kameo/registry/1.0.0. The DHT code for kameo is ~1200 LOC in registry.rs, you should be able to follow along with what kameo is doing in regards to the Kademlia DHT in that file.

Kameo doesn't have a way to configure this, which has been chosen for simplicity reasons, but if needed a PR would be welcome to make the Kademlia DHT more configurable.

[timofdev]

Protocol mismatch: go-libp2p-kad-dht appends /kad/1.0.0 (kameo protocol format doesn't follow libp2p Kademlia standard — breaks Go interop)

I'm very close to getting Go - Rust interop working! mDNS discovery and connection work fine, and kameo sees the Go peer (RoutingUpdated events).

However, there's a protocol mismatch:

• kameo uses: /kameo/registry/1.0.0
• go-libp2p-kad-dht uses: /kameo/registry/kad/1.0.0 (it appends /kad/1.0.0 to any prefix)

The Go DHT adds the Rust peer to routing table, but it gets removed immediately because DHT messages fail due to protocol ID mismatch.

After investigating, I found that kameo doesn't follow the standard libp2p Kademlia protocol format. The standard format is /<namespace>/kad/<version> (e.g., /ipfs/kad/1.0.0), but kameo uses /<namespace>/<version> without the /kad/ segment. Because of this, the DHT routing tables don't sync - Go adds the Rust peer but it gets removed immediately because DHT messages fail.

Since you mentioned PRs are welcome, I'd like to propose one. Here's the issue/PR description:

---

Title: feat: Use standard libp2p Kademlia protocol format for cross-implementation compatibility

Problem:
Kameo uses /kameo/registry/1.0.0 as DHT protocol ID, which doesn't follow the standard libp2p Kademlia protocol format /<namespace>/kad/<version>.

This breaks interoperability with other libp2p implementations (Go, JS, etc.) that follow the standard. For example, go-libp2p-kad-dht expects protocol IDs in format /<prefix>/kad/1.0.0.

Proposed Solution:

1. Change default to /kameo/registry/kad/1.0.0 (standard format)
2. Add configuration to allow users to set custom protocol ID

Impact:
This would enable kameo to work with Go, JavaScript, and other libp2p implementations out of the box.

---

Would this kind of PR be acceptable?

[tqwewe]

Yes absolutely, your proposed solution sounds good, PR would definitely be appreciated