Client: Feature Request: Team public folders

[iwburns]

I'm sorry if this has been suggested before elsewhere; I searched but didn't find anything.

I think it would be really nice if there was a way for teams to have a public folder in addition to the current private folder under /keybase/team/.

This would allow teams to have a homepage served at keybase.pub and would allow them to put out public documents as well. (I'm mostly thinking of larger open-source dev teams when I suggest this, but I'm sure other teams would have a use for this.)

With that said, I'm not sure where this public folder would go. The most straightforward way to structure it (I would think) would be to have:
/keybase/team/public/[teamName]
/keybase/team/private/[teamName]

But that wouldn't be easy to switch to since we've already got:
/keybase/team/[teamName]
for private folders right now.

Is this something that you would be interested in doing?

Edit: grammar

[maxtaco]

On our internal roadmap. We would also need a notion of a public team whose membership is visible to all, to verify writers and writes. Please :+1: if your team also would use such a feature. Thank you!

[iwburns]

Thanks so much for the quick response; very happy to hear this is on the internal roadmap!

We would also need a notion of a public team whose membership is visible to all, to verify writers and writes.

I guess I didn't realize that teams are currently completely private (makes sense, just didn't think about it). I'm assuming this means in the future there will be two types of teams (public/private) and you'll have to specify which type of team you're creating during the creation process?

If so, I'm assuming there will be restrictions on whether or not a team can switch to private (or public) after they've been created.

Maybe that's too much to ask at this point. I realize there's probably still very much to do before the exact behavior of that part of the system can be nailed down.

[dabura667]

This seems like a good use case for subteams methinks.

You could have a few people join a subteam for outward facing public folders, and the public wouldn't know of all the members of the parent team.

[iwburns]

Yeah, I think that would work pretty well.

The only issue I see with that is that it might be an annoyance for "public" teams to have to create a sub-team and add everyone to it if what they _really_ want is for the whole team to be public.

Which also means there'd be no way for a team to _prove_ that there are no "private"/"hidden" team members.

Not sure if either of those are worth being concerned about at this point though.

EDIT: Ideally, I'd like for teams (and sub-teams) to be private or public, so that you can create whatever kind of structure you'd like:

1. Public team with private sub-teams
2. Private team with public sub-teams
3. Public team with public sub-teams
4. Private team with private sub-teams

This would allow the most flexibility, but I don't know how hard that is to do in the context of Keybase.

[dabura667]

there'd be no way for a team to prove that there are no "private"/"hidden" team members.

The point is that I, as a consumer of the data, need to know that a member of the public team signed the data. If I see data signed by an unknown user, I just ignore it. No need to prove “no hidden members”

[iwburns]

That's true, and that totally makes sense.

I really just meant that point to be considered from a transparency perspective instead of a security perspective.