Make it clear when a thread is becoming public

[jamesnvc]

Should be clear to people when a thread has become public; maybe have some way of enforcing "this cannot become public"?

[Ashe]

To take this further: While a thread may not be public, you could invite people to the conversation against the other user's will. I think there's an important talking point here as well: Do you wish to merge the terms conversation and thread?

If you take slack, you either privately message, or you talk in a channel, not both. I really love the work flow of Braid, how you talk to people and can pull other people or even entire topics to the conversation, but care must be taken so that A. things cannot be abused (leaking info or exposing personal conversations) and B. user's can get a better idea of where they are talking. I'm not really sure how you'd go about this.

If your target audience is purely development teams then it's less of an issue, but if you're trying to make an open-source alternative to casual slack users (and discord users essentially, as its just a clone) then maybe a plan should be made as how these threads are supposed to be handled.

[jamesnvc]

Yeah, I think this is a hard problem that really depends on use-case. We've just been using Braid for inter-company development talk mostly, so it hasn't been an issue, but with larger, more public groups, it definitely could.

At the very least, we should probably warn that a thread is becoming public, to guard against accidental tagging...maybe require all the participants of the thread to agree?

[Ashe]

I think that's assuming that everyone is in equal contribution to a thread. If you imagine it in terms of a games development studio with 1 team leader and 3 developers, 2 developers could choose to so overrule what an admin says. This isn't a massive pitfall as I doubt it'd happen often, it really does depend on your target audience. It depends on whether you, as Braid lead developers, want to keep Braid going in its current direction that's basic but effective, or whether you want to layer on rules and systems to 'normalize it'.

I personally think that making every single conversation it's own thread is very limiting in this regard. If I tag a friend into a conversation, they could tag any number of people and take ownership. Sure, Braid is about small conversations so you'd just ditch that conversation - the question is, are you comfortable with that? Are there any use cases we can anticipate where it's a bad thing where participants are all equally in ownership of a thread?

There are two reasons I think moderation matters:

1. There must be a way to ensure sensitive content is under control of some responsible party (video game leaks?)
2. Slack prides itself on being searchable, you can deep dive back into history. If you constantly switch threads because something happens, how easy is it to retrieve data from an old thread (especially how they aren't named and their only distinguishing features are tags and participants?).

Some things to think about that are simply design decisions (replace should for will at times as I don't know what's planned):

• Should the person who started the thread have any kind of power inside the thread?
• Should the people participating in a thread have any say in what should and shouldn't happen (if the owner decides to say, release the content of the thread publicly)?
• Should there be a distinction between original vs invited parties? If a thread is placed into a public tag, a griefer could go crazy and tag that conversation under every tag they can think of. As I mentioned above, switching threads is fine but it does mean that the previous thread becomes harder to search
• Should there be a way of un-tagging people and topics? All of the questions above then need to be answered again with un-tagging, as someone could untag someone important and 'steal' content.