Make ipfs-pubsub-room work with js-ipfs-api about ipfs-pubsub-room HOT 14 OPEN

@haadcode that's a great point, it really forbids us from using a non-local node with this package, but I think this is a limitation of ipfs-api and the HTTP API, not this package. Somehow, the IPFS API should allow to open raw private streams to specific nodes.

Also, I believe that encryption and authentication should not be a concern of this package, it should be addressed further up the stack, maximising separation of concerns.

As an alternative to fixing ipfs-api, I think there's nothing preventing you from building this mechanism on top of this package by "broadcasting" p2p messages in the way you described...

@haadcode @diasdavid thoughts?

from ipfs-pubsub-room.

@haadcode that's super, I think they may be very useful in some of upcoming work: I think I'm going to need direct communication, presence, but not broadcast.

I'd be super glad these repos come join the ipfs-shipyard org!

from ipfs-pubsub-room.

08:01 <@daviddias> the reason why it uses libp2p is so that all the comms between 2 peers are encrypted e2e
08:02 <@daviddias> if you use PubSub as you propose, then any peer can eavesdrop in other peers messages

from ipfs-pubsub-room.

08:03 <@haad> daviddias: yup, in my proposal the encryption would have to happen on app/user-layer

from ipfs-pubsub-room.

@pgte totally agreed. I think I'll go ahead and create the module as laid out ^ and see what that gets us (not sure when I get to work on it though). Ideally, as noted by all of us I think, we should have a way to hook into libp2p streams/connections directly from the API to get the benefits of libp2p.

from ipfs-pubsub-room.

Any updates?

from ipfs-pubsub-room.

Nope. This depend on ipfs-api, which would have to be standardised and implemented in go-ipfs and js-ipfs.

from ipfs-pubsub-room.

For now, we can use it only with js-ipfs?

from ipfs-pubsub-room.

from ipfs-pubsub-room.

Update on OrbitDB side is that I ended up first taking out the libp2p functionality from ipfs-pubsub-room and created a module for 1-to-1 communication https://github.com/haadcode/ipfs-pubsub-1on1. Note that it's not a secure channel in the way ipfs-pubsub-room has: anyone can join the pubsub topic and listen in on it. This will change in the future, however.

Second, as ipfs-pubsub-room then only had the room notifications functionality left and we didn't want to use a fork, I created another module to do only that: https://github.com/haadcode/ipfs-pubsub-peer-monitor.

Essentially, those two modules have the same functionality as ipfs-pubsub-room but broken down per "abstraction", works with js-ipfs-api but also provide less security guarantees. I've created them in order to be able to keep moving on in OrbitDB, but the overall goal here is to be able to use ipfs-pubsub-room room in the long run once we have the libp2p connections available through js-ipfs-api.

@pgte you may want to check those modules and see what you think. Would be also more than happy to transfer the repos to shipyard if you feel they benefit the community and work done here.

from ipfs-pubsub-room.

@pgte tried to transfer the repos but got an error "You don't have the permission to create repositories on ipfs-shipyard".

Mind adding me to the org (would also love to keep admin/write access to the repos I'm transferring)?

from ipfs-pubsub-room.

It seams like I don't have enough permissions for that. @diasdavid an you help on this?

from ipfs-pubsub-room.

Done :)

from ipfs-pubsub-room.

@diasdavid @pgte thank you! ♥️

The repos have been transferred respectively at:

• https://github.com/ipfs-shipyard/ipfs-pubsub-1on1
• https://github.com/ipfs-shipyard/ipfs-pubsub-peer-monitor.

I believe I'm still the only one who can publish on npm and would be happy to add another maintainer for that, but you can also just give a shout and I'll publish when needed. We can cross that bridge when we get there.

from ipfs-pubsub-room.