Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reverse PubSub ? #14

Open
MichaelMure opened this issue Jun 21, 2017 · 0 comments
Open

Reverse PubSub ? #14

MichaelMure opened this issue Jun 21, 2017 · 0 comments

Comments

@MichaelMure
Copy link

Pubsub messaging is by default a N publishers to M listeners.

When you start adding signing (ipfs/notes#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 (ipfs/kubo#3397 (comment)). 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.

@MichaelMure MichaelMure mentioned this issue Jun 21, 2017
24 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant