Pubsub messaging is by default a N publishers to M listeners.
When you start adding signing (https://github.com/ipfs/notes/issues/236) you get a 1 publisher to N listeners configuration. (The publishing private key can be copied so it's more like +→N, but I'm going to ignore this)
I have the opposite need (N --> 1) as well:
Regular PubSub: 1→N
1 publisher publish messages for N subscribers
subscribers can read the message and verify that it comes from the publisher
Reverse PubSub: N→1
N publishers publish messages for 1 subscriber
only the subscriber can read the message
I have this need because I want to implement a file-sharing social network. I need to send some messages between users identified by a keypair. This keypair is not the node keypair, so I can't directly use ipfs p2p (https://github.com/ipfs/go-ipfs/issues/3397#issuecomment-309306293). Pubsub is convenient because the recipient can simply listen to a topic named with its public key. I don't need to track which node an identity is on. There is no problem if an identity is copied on another node and run at the same time.
Has this been considered ? Surely I can implement this on top of the regular pubsub but maybe I'm not the only one with a usecase for this ? It could be implemented directly in the pubsub, be made more efficient and easier to use for someone implementing an app.
Pubsub messaging is by default a N publishers to M listeners.
When you start adding signing (https://github.com/ipfs/notes/issues/236) you get a 1 publisher to N listeners configuration. (The publishing private key can be copied so it's more like +→N, but I'm going to ignore this)
I have the opposite need (N --> 1) as well:
Regular PubSub: 1→N
Reverse PubSub: N→1
I have this need because I want to implement a file-sharing social network. I need to send some messages between users identified by a keypair. This keypair is not the node keypair, so I can't directly use
ipfs p2p(https://github.com/ipfs/go-ipfs/issues/3397#issuecomment-309306293). Pubsub is convenient because the recipient can simply listen to a topic named with its public key. I don't need to track which node an identity is on. There is no problem if an identity is copied on another node and run at the same time.Has this been considered ? Surely I can implement this on top of the regular pubsub but maybe I'm not the only one with a usecase for this ? It could be implemented directly in the pubsub, be made more efficient and easier to use for someone implementing an app.