Allow one way traffic

[taterhead247]

Giggle had a scenario where he wanted posts in #virtualworkouts from f3nation to show up in a channel in his Slack. But I don't really want their region-specific chatter showing up in the nation's. It would be nice to have an option to 1) only send, 2) only receive, 3) send and receive.

[sprocktech-dev]

This is interesting. I think a way to handle this would be to add a special prefix to the message, maybe NO_SYNCBOT or something. I'll think about this more.

One way this can be done now is to "pause" the channel sync temporarily and then "resume" it after.

[taterhead247]

I'm saying this as someone who has looked at 0 lines of this code. Couldn't you have a configuration setting to make it go only one way, only the other way, or both ways?

[sprocktech-dev]

Ok. I think I understand the use case now. Basically you're thinking of way to subscribe to a Nation Slack channel in a Region's Slack workspace, without a PAX needing to be a user in the Nation Slack and/or switch over to that workspace to view messages.

I think adding a permissions option on this modal (see screenshot) for "Read Only - Subscribers will get all messages from this channel, but can't send messages back" and "Sync - Subscribers will get all messages, and all messages they send in their channel will sync back to this channel"... something like that.

Note that this modal title says "Sync Channel" and in a previous iteration it said "Publish Channel". I think going back to the "Publish Channel" language will make more sense. Then you are "publishing" on one side, and "subscribing" on the other, and then depending on the publishing permission, it will be "subscribe/read-only" or "sync-both-ways".

@taterhead247 Is that what you're thinking?

[taterhead247]

Doesn't have to be a Nation channel, but yes, there are use cases where message delivery only goes one way. Another use case could be sector or state-wide announcements.

This actually brings up more questions. I read through the .md's so sorry if this is written somewhere and I missed it. Say I sync a channel to a group. Can workspace in that group sync with my channel? Is there an approval/acceptance process?

I wonder if it makes sense to model this off of MQTT/PubSub/Whatever. Workspaces can publish to syncbot in form "Workspace Name/Channel Name" (but, really it's team/channel IDs in the background. And then workspaces can peruse the list of topics and choose what to subscribe to and where in their workspace it should land. That would also eliminate the need for Workspace Groups maybe.

I think that's kinda/mostly what you have, but just from a different angle? I don't know. I haven't been too plugged in. Feel free to tell me if I'm way off base

[sprocktech-dev]

Here is a screenshot of what the groups/channels would look like. There is one group here called "Testing 1-2-3", with three member workspaces and two published channels.

There is notification/approval required to join a group. This is different than before. I wanted to make it so workspace admins have to "trust" each other before they can sync channels. Once in the group, you can publish/subscribe to channels pretty freely.