OpenBazaar Desktop Nodes Not Able to See Chat Nodes

[hoffmabc]

I think this might not be a fixable problem, but I cannot see the openbazaar.chat nodes from the desktop client.

[jackkleeman]

This is because browser nodes are not 'online' in the same sense; they cannot receive inbound initiating connections from a peer, basically. This is not something that is easily fixed, given that receiving inbound connections in a browser is very difficult, but we are looking into WebRTC to solve this (as are the libp2p developers). This is probably a few months away.

What we can do instead is have openbazaar.chat nodes have proper OpenBazaar profiles, and therefore you would be able to look them up in the desktop client, and send them an offline message. We will implement this very soon.

[JustinDrake]

If the buyer initiates an action with an online vendors (e.g. chat or purchase) the open connection should persist, and the node should there be seen as online by the desktop client. (This will probably require a minor change in the desktop client.)

Not being online unless the buyer initiates an action buys our buyers two things:

1. Enhanced privacy. For example, it is not leaked when they are "online" or "offline", unless the buyer explicitly opts-in contacting a vendor or another node.
2. Spam protection. Any node can send spam to any online super easily. Being offline mitigates that, especially if we do not publish profiles.

[jackkleeman]

I don't think this will require any change to the desktop client @JustinDrake, it currently shows all peers to which is has a connection. However until we add profiles, the browser peers will be greyed out and won't be messageable.

[JustinDrake]

the browser peers will be greyed out and won't be messageable

That part may need a change to the desktop client. It should be able to message any node connected to it, regardless of profile existence.

[cpacia]

fwiw none of the messages I'm sending from the browser are getting through to desktop despite ipv6 and upnp enabled. My node does not show as online in the UI either.

Also it doesn't appear that you're not publishing the public keys in the dht. I changed it to save the pubkey from an incoming offline message but it will not persist through sessions make future offline communication not possible.

[JustinDrake]

fwiw none of the messages I'm sending from the browser are getting through to desktop despite ipv6 and upnp enabled

strange. It works for us. (I sent @hoffmabc a message earlier today from the browser.)

it doesn't appear that you're not publishing the public keys in the dht.

We should be publishing the public keys to the dht. I'll test that further.

[hoffmabc]

It worked fine for me just as a reference point. And I got your message @justindrake

[cpacia]

So I'm not that familiar with how ipfs decides the addresses to listen on but my node isn't listening on the open internet on ipv4/ws. Only ipv6/ws. I suspect you are only using ipv4?

I'm not sure what the problem is with ipfs. It's listening on internal addresses on ipv4/ws just not an external one.

[JustinDrake]

ipv6 addresses should work out of the box but I'll test it myself. Would you mind posting your PeerId and ipv6 address?

[jackkleeman]

I had an issue binding to external websocket addresses in ipfs when I was running a server on Amazon AWS. No such issue in digitalocean. @cpacia

[cpacia]

This is my desktop not a vps. Address is /ip6/2601:18d:8a01:1110:3047:39d:65a7:13fd/tcp/9005/ws id: QmZXGKrRRe5RTDhvzhZfSTe8vYBDGV7HBoNz5FS3U9FnUa

I'll leave it running for most of today

[jackkleeman]

Our pinger thinks you are offline. I suspect the reason is that you have an insanely large number of addresses in the dht, and our pinger isn't getting through them very quickly, and maybe is therefore deciding you are offline. Is this possible @JustinDrake

The messages will be going into the dht for you, most likely.

[cpacia]

Is this going out over the websockets or relayed through a server?

[jackkleeman]

If our server thinks you're offline, we won't even attempt to go over websockets, it goes to a server, which then if you're online uses offline_relay, and if you're not posts to dht. Offline_relay catches situations where you're online but not listening on websockets.

On Sat, 22 Apr 2017, 17:14 Chris Pacia, notifications@github.com wrote:

Is this going out over the websockets or relayed through a server?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/duosearch/openbazaar.chat/issues/3#issuecomment-296379922, or mute the thread https://github.com/notifications/unsubscribe-auth/AQSEtaTeKaH5UsfcwfBFVhwSJEAn4fLNks5ryhligaJpZM4NEUE3 .

[cpacia]

What are you using to check online status? The status endpoint will iterate over all the addrs and I've never seen it fail to correctly identify if someone is online.

[jackkleeman]

We aren't using an OB node, it's a custom solution where we ping all the addresses and see if we have had a successful ping within a given window. If there is an ipfs command that would do this more cleverly, we'd love to know about it.

[cpacia]

It's not an ipfs command but that's just how libp2p works when you send a message. It handles address selection for you. I just send a PING message from the ob protobuf and it does the address selection automatically.

[jackkleeman]

I am not sure exactly how we are doing it, I think we are letting ipfs pick the best address too, but we have had an issue in the past with not pinging fast enough to get a fast response. I think our metric for offline is 'no successful ping in the last x seconds', which is likely the issue given ipfs only uses a certain level of concurrent connection attempts and thus would take a while to connect to you.

We are seeing you as online now, anyways, so give it another go. I suspect online messaging may timeout given how many addresses you have - each one will have its own websocket attempt and they don't immediately fail on a bad address, but the offline_relay route should succeed.

If you're interested, your address list is here: https://proxy.openbazaar.chat:8000/info/peer?&peerId=QmZXGKrRRe5RTDhvzhZfSTe8vYBDGV7HBoNz5FS3U9FnUa This is the api used by both the browser client, and the relay server for determining how to reach you

Edit: Our relay server is actually having trouble reaching you Chris, I suspect it could be ipv6. It now thinks it may have sent one to you, let me know if you got anything.

[cpacia]

yes I did get that message. The response failed though because it couldn't find the public key. Not sure why it couldn't find the public key though because I thought ipfs saves all keys in memory upon first connection.

[JustinDrake]

The public key is shared in the secio handshake. We should make sure it's cached.

[jackkleeman]

The response is going over offline messaging, for which it does a public key lookup. I'm not sure what the best way would be to store known public keys

[jackkleeman]

@cpacia potentially the issue was just that my public key has expired in the dht, we are not republishing. However, @hoffmabc had a similar issue with his own created identity, so we suspect there could be problems with public key lookups - we have verified that we are publishing them correctly to dht on identity creation.