Private or Non-Broadcast Messages

[IppSec]

Is there any concept of sending a message to a specific subscriber/group within this? Or is that on the roadmap at all?

Also - It looks like the example is slightly wrong here:

endpoint.register_route(app, "/pubsub")

I believe it needs to be:

endpoint.register_route(app, path="/pubsub")

If this doesn't make sense, I was hoping to have the same topics (chat_messages, events, etc) for various user levels. (guest, user, admin). So they would subscribe to /admin/chat_messages and get chat messages from all topics, whereas users would get messages from only the users channel. Hopefully that makes sense.

[orweis]

Hey @IppSec :)

TL;DR - sure simply have the 'specific' clients / group members subscribe to the same unique topic (which you can also protect with access-control tokens)

There is no current first-class-citizen concept like the direct messages you're suggesting; since this is a pub/sub pattern solution, after all ;-).

That being said if you want to create something like that on-top of the pub/sub - it would be very easy; simply have the two direct parties subscribe to the same topic, for example the topic can be "{user-id-1}:{user-id-2}", you can also have the server secure that direct channel for only the allowed members through the recently added topic JWT restriction feature (Seetests/server_notifier_callback_test.py).
And of course each client can subscribe to multiple such topics and others.

If you want a direct 1x1 communication without a server I suggest you take a look at the underlaying fasti-websocket-rpc package.

I think you're correct about endpoint.register_route ! :) - would you like to open a pull request to fix that (in the readme and tests?)
So you can have your contribution immortalized on Github? (If not it's okay, I'll do it later)

[IppSec]

Thanks for the reply. The server secure thing/jwt restriction answers my question perfectly, I was worried about it due to the "ALL_TOPICS" piece allowing for subscription to a "hidden" topic, not realizing where auth could be applied. And yes you were right it violates the pub/sub pattern solution and "broadcasts". I am completely new to WebSockets and really really liked the simplicity of the library after watching the talks. So was hoping to tweak it slightly which will hopefully prevent me from doing something universally stupid :)

Thank you very much! I'll submit a pull request later today for the example fix.