There’s no way to prevent prefix subscriptions either in principle or for certain prefixes.
Using RPCs would be a workaround, but it’s a somewhat strange use of the pattern.
When using dynamic authorization, you can also authorized based on the sessionID, so for client-to-client communication this would work without using authentication.
You mean, that I had to add some code to my crossbar, that would allow subscription to chat.incoming.sessionID and reject all requests, where the sessionID does not correspond.
Well this will be the first time I’ll modify code running on the crossbar itself. Will give it a shot.
Have to read the spec. I assume I can block subscribes only but allow publish?
Just out of curiosity: How are you exchanging the secret between the clients?
Ouch the question that hurts
Initially (in order to avoid further thinking) I thought about out of band communication (SMS / phone / PGP-mail ) which is good enough for some use cases.
One use case would be a set of dedicated apps (running on a few machines by power users having access to the secret key) which should be allowed receiving confidential information from many clients.
thus everybody should be allowed to publish, but just some privileged users should be allowed to receive.
Another use case (in the later future) would be something like the creation of private chat rooms with no centralized intelligence or master application and no encryption apart from the https protocol to communicate wit a rather stupid crossbar.
I wanted to be able, that such a chat client could use an out of the box crossbar without any modification (just tell anybody to pip install and run a default Xbar, publish its address and let all participants connect being able to create private groups amongst them). Imagine people playing a board game and wanting to have private conversations (2 or more persons per chat) via a preloaded mobile phone’s app (just having to enter the IP of a plain simple crossbar)
I imagined it like this. (idea is as I said to have no centralized intelligence)
Everybody can see the list of participants in a certain world (use for example the channel “players_of_game.game1” )
Whenever a player joins, he notifies every other subscribed player about his presence ("hello I’m there and my name / id is)
Everbody who’s still alive will reply with “I am here”. I think there’s more optimal solutions to know who’s alife and subscribe to a channel but this would do.
At this point all participants know about each others presence.
Now any player can register an RPC call with a predefined naming style. So now each player has a way to send a secret message to any other player.
Whenever one wants to enter into a private communication with somebody one could send a chat request via RPC and receive a random invisible pub/sub channel id to communicate with.
If hidden channels existed the problem would now be solved without any specialized central crossbar.
Now I could establish secure point to point chats and I could create group channels and share them via the point to point chats with all participants which could participate at a specific
Am I the only one who would benefit from non observable ‘wildcardable’ channels?
An alternative approach would of course be to create a special crossbar configuration and deliver it as part of the default repository allowing such chats.
However I really liked the idea, that crossbar itself doesn’t have to do any book keeping of chat rooms and participants except the default register / pub / sub / call methods.
On Friday, August 21, 2015 at 1:36:49 PM UTC+2, Alexander Gödde wrote: