https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3CCR5CFKD4Y5CT.3RLWZWX54YMRW%40taiga%3E sourcehut Log in -- Register ~sircmpwn/sr.ht-discuss * archives * patches * new post 10 9 RFC: Organizations Drew DeVault Details Message ID DKIM signature pass Download raw message 8 hours ago A proposal: we should implement organizations, which are an entity representing a group of users which can collectively own resources like git repositories. THE BASICS Organizations are named without a prefix (differs from previous proposal a few years back). I am "~sircmpwn" and I am a member of the "sourcehut" organization. Some examples of resources owned by orgs: git.sr.ht/sourcehut/todo.sr.ht sr.ht/sourcehut/sourcehut sourcehut/discuss@lists.sr.ht sourcehut.srht.site Organizations and users share a common namespace; a user cannot have the same name as an org and vice-versa. The lack of a prefix may cause some conflicts with internal SourceHut routes; we will have to audit them to understand the severity of this conflict. ROLES & TEAMS Members of an organization can be organized into teams and sub-teams. sourcehut/devs sourcehut/devs/backend sourcehut/infra sourcehut/docs All members are a member of the organization itself (simply sourcehut), but may also be a member of any number of teams or sub-teams. Sub-teams do not inherit the members of their parent team or vice-versa; they are simply a means of namespacing members per the needs of each org. Within the organization, permission to manage the organization itself can be handed out along these lines: - Organization details (i.e. public profile); implicit read-only, optional read-write - Billing details; read-only or read-write - Membership and permissions; read-only or read-write - CRUD rights over resources (e.g. permission to create or delete a repository under the org); read-only or read-write Public insight into the membership of the organization is configurable; each team can be public or private and the composition of the org and of each team may also be public or private, on a per-user or global basis. Teams can be added to access control lists on resources around sourcehut. For instance, I could add an ACL entry for lists.sr.ht which gives moderation access to sourcehut/mods. Teams can also be mentioned and assigned to tickets on todo.sr.ht, e.g. by mentioning @sourcehut/infra on a ticket. BILLING Up to some percentage of the membership of an organization (say, for the sake of argument, 50%) must have a paid SourceHut account, either directly or through financial aid. Users can form grassroots organizations on SourceHut so long as a sufficient number of them have paid accounts, with no further fanfare regarding billing. Additionally, organizations may have their own billing information associated with the org itself. They can use this to sponsor the accounts of their members, allowing the billing for a tightly coupled group of users (e.g. staff members at a company or organization) to have access to centralized billing. Through this they can meet the 50% requirement without having individual members pay up. Users who are members of an organization and have a paid account, regardless if by their own means or by way of sponsorship from the org, have access to both the org's resources and private ownership of resources on SourceHut, e.g. can submit builds.sr.ht jobs on their own account. Org members with unpaid accounts can access the org resources, but cannot hold private resources on SourceHut. The goal of this approach is to allow users to form grassroots orgs without too much hassle over payment; to allow companies and formal organizations to manage billing centrally for their members; and to balance things such that adding Joe Support Tech to the bug trackers does not mean you have to pay for a full SourceHut account for them, while still incentivizing people to pay for more than 50% if their members would benefit from access to private resources (e.g. the dev team might all have paid accounts regardless of if it exceeds the 50% minimum, just because it's worth the money to them). An emergent behavior of this system is that a user who is a member of several organizations can have their account sponsored by one of them and then have their paid account contribute to the 50% threshold of _all_ of them. The politics of who pays for whose account is not my problem, thank you, good luck sorting that out. API Access Open question as to how to structure user's access to their org resources via the API. Should we have special OAuth tokens which grant access to the org resources? (probably not -- existing user credentials may be enough?) Will have to do a separate draft of some GraphQL changes. Ingo Hoffmann Details Message ID <198324272.495038.1678721337656@office.mailbox.org> In-Reply-To (view parent) DKIM signature pass Download raw message 7 hours ago Hi Drew, this is the first time I'm involved in this process, but here are my thoughts. > On 13/03/2023 14:59 GMT Drew DeVault wrote: > > > A proposal: we should implement organizations, which are an entity > representing a group of users which can collectively own resources like > git repositories. > > THE BASICS > > Organizations are named without a prefix (differs from previous proposal > a few years back). I am "~sircmpwn" and I am a member of the "sourcehut" > organization. Some examples of resources owned by orgs: > > git.sr.ht/sourcehut/todo.sr.ht > sr.ht/sourcehut/sourcehut > sourcehut/discuss@lists.sr.ht > sourcehut.srht.site > > Organizations and users share a common namespace; a user cannot have the > same name as an org and vice-versa. > > The lack of a prefix may cause some conflicts with internal SourceHut > routes; we will have to audit them to understand the severity of this > conflict. I think the basics are spot on. > ROLES & TEAMS > > Members of an organization can be organized into teams and sub-teams. > > sourcehut/devs > sourcehut/devs/backend > sourcehut/infra > sourcehut/docs > > All members are a member of the organization itself (simply sourcehut), > but may also be a member of any number of teams or sub-teams. Sub-teams > do not inherit the members of their parent team or vice-versa; they are > simply a means of namespacing members per the needs of each org. > > Within the organization, permission to manage the organization itself > can be handed out along these lines: > > - Organization details (i.e. public profile); implicit read-only, > optional read-write > - Billing details; read-only or read-write I think only org admins should have access to billing details and only some of these admins could have read-write access. Org Owners group? > - Membership and permissions; read-only or read-write > - CRUD rights over resources (e.g. permission to create or delete a > repository under the org); read-only or read-write > > Public insight into the membership of the organization is configurable; > each team can be public or private and the composition of the org and of > each team may also be public or private, on a per-user or global basis. > > Teams can be added to access control lists on resources around > sourcehut. For instance, I could add an ACL entry for lists.sr.ht which > gives moderation access to sourcehut/mods. > Teams can also be mentioned and assigned to tickets on todo.sr.ht, e.g. > by mentioning @sourcehut/infra on a ticket. I like these ^^ a lot. How fine-grained should/can this be? For example, if everything is either read-only or read-write, could we have users trigger builds under the org account only if they have RW access to a specific repository? That way only "admins" or bots would be able to trigger builds for sourcehut/devs. > BILLING > > Up to some percentage of the membership of an organization (say, for the > sake of argument, 50%) must have a paid SourceHut account, either > directly or through financial aid. Users can form grassroots > organizations on SourceHut so long as a sufficient number of them have > paid accounts, with no further fanfare regarding billing. > > Additionally, organizations may have their own billing information > associated with the org itself. They can use this to sponsor the > accounts of their members, allowing the billing for a tightly coupled > group of users (e.g. staff members at a company or organization) to have > access to centralized billing. Through this they can meet the 50% > requirement without having individual members pay up. > > Users who are members of an organization and have a paid account, > regardless if by their own means or by way of sponsorship from the org, > have access to both the org's resources and private ownership of > resources on SourceHut, e.g. can submit builds.sr.ht jobs on their own > account. Org members with unpaid accounts can access the org resources, > but cannot hold private resources on SourceHut. > > The goal of this approach is to allow users to form grassroots orgs > without too much hassle over payment; to allow companies and formal > organizations to manage billing centrally for their members; and to > balance things such that adding Joe Support Tech to the bug trackers > does not mean you have to pay for a full SourceHut account for them, > while still incentivizing people to pay for more than 50% if their > members would benefit from access to private resources (e.g. the dev > team might all have paid accounts regardless of if it exceeds the 50% > minimum, just because it's worth the money to them). > > An emergent behavior of this system is that a user who is a member of > several organizations can have their account sponsored by one of them > and then have their paid account contribute to the 50% threshold of > _all_ of them. The politics of who pays for whose account is not my > problem, thank you, good luck sorting that out. > > API Access > > Open question as to how to structure user's access to their org > resources via the API. Should we have special OAuth tokens which grant > access to the org resources? (probably not -- existing user credentials > may be enough?) Will have to do a separate draft of some GraphQL > changes. I think this there could be a special OAuth token, or another method, from user->org so there's a manual "trust" process between the two parts, if that makes sense. Drew DeVault Details Message ID In-Reply-To <198324272.495038.1678721337656@office.mailbox.org> (view parent) DKIM signature pass Download raw message 7 hours ago On Mon Mar 13, 2023 at 4:28 PM CET, Ingo Hoffmann wrote: > I think only org admins should have access to billing details and only some > of these admins could have read-write access. Org Owners group? I wanted to avoid establishing "admin" as a role that actually exists, and instead let organizations govern their users with fine-grained permissions rather than coarse roles like "admin". > I like these ^^ a lot. > > How fine-grained should/can this be? > > For example, if everything is either read-only or read-write, could we have > users trigger builds under the org account only if they have RW access to > a specific repository? That way only "admins" or bots would be able to trigger > builds for sourcehut/devs. Not sure if I understand this question; repos and orgs are separate entities. > I think this there could be a special OAuth token, or another method, > from user->org so there's a manual "trust" process between the two > parts, if that makes sense. After some thought I wanted to avoid the double trust thing, given that users can do anything via the web UI once granted permission it does not make sense to separate that permission out for API access. Though perhaps we could do a github-style oauth thing and let org admins authorize specific oauth clients/integrations for access to their resources. Ingo Hoffmann Details Message ID <1876373417.502000.1678724596440@office.mailbox.org> In-Reply-To (view parent) DKIM signature pass Download raw message 6 hours ago > On 13/03/2023 15:32 GMT Drew DeVault wrote: > > > On Mon Mar 13, 2023 at 4:28 PM CET, Ingo Hoffmann wrote: > > I think only org admins should have access to billing details and only some > > of these admins could have read-write access. Org Owners group? > > I wanted to avoid establishing "admin" as a role that actually exists, > and instead let organizations govern their users with fine-grained > permissions rather than coarse roles like "admin". I see where you're coming from. My main concern is that, IMHO, billing should be more protected/has an extra layer of security. > > I like these ^^ a lot. > > > > How fine-grained should/can this be? > > > > For example, if everything is either read-only or read-write, could we have > > users trigger builds under the org account only if they have RW access to > > a specific repository? That way only "admins" or bots would be able to trigger > > builds for sourcehut/devs. > > Not sure if I understand this question; repos and orgs are separate > entities. I was thinking about the matrix of paid/non-paid users, as you mentioned, and how to make it easier for non-paid customers to access paid resources under the discretion of a paid org member. > > I think this there could be a special OAuth token, or another method, > > from user->org so there's a manual "trust" process between the two > > parts, if that makes sense. > > After some thought I wanted to avoid the double trust thing, given that > users can do anything via the web UI once granted permission it does not > make sense to separate that permission out for API access. Though > perhaps we could do a github-style oauth thing and let org admins > authorize specific oauth clients/integrations for access to their > resources. Hmm, could it be that a user is only added to an org after giving the org maintainer an OAuth token? Wolf480pl Details Message ID In-Reply-To <1876373417.502000.1678724596440@office.mailbox.org> (view parent) DKIM signature pass Download raw message 5 hours ago Disclaimer: I'm don't actively use sourcehut, just thought my insight could be useful W dniu 13.03.2023 o 17:23, Ingo Hoffmann pisze: > I see where you're coming from. My main concern is that, IMHO, billing should > be more protected/has an extra layer of security. I think if sourcehut wants to be used by companies, it's important to be able to designate a user who can access *only* billing, and not have any write access to repositories or team membership. This allows giving someone from accounting/finance access to just the information they need to pay the invoices without going through the person managing access. W dniu 13.03.2023 o 15:59, Drew DeVault pisze: > Open question as to how to structure user's access to their org > resources via the API. Should we have special OAuth tokens which grant > access to the org resources? (probably not -- existing user credentials > may be enough?) Will have to do a separate draft of some GraphQL > changes. I think it's very useful to be able to create some sort of "machine accounts" i.e. API tokens that have access to specific resources of an organization, but don't have their own email or password, don't own resources, and can be centrally managed by organization "admins" (or whoever has a relevant "manage bots" permission). This can be useful for all kinds of automation, like Jenkins, repo mirroring, etc. Amolith Details Message ID <87fsa8eenu.fsf@secluded.site> In-Reply-To <1876373417.502000.1678724596440@office.mailbox.org> (view parent) DKIM signature pass Download raw message 5 hours ago Ingo Hoffmann writes: > I see where you're coming from. My main concern is that, IMHO, billing should > be more protected/has an extra layer of security. I had the same concern while initially reading the proposal. I checked the billing page and, personally, wouldn't have a huge problem with any of my employees having read-only access to the information here. It shows card type, last four digits, postal code, expiration month, and when you paid how much. If it showed more sensitive information, like more of the card details, I would absolutely want some knob to twist to disable read access. _Ideally_, that page could be hidden from all but a select few people (those who don't need to know anything about payment details shouldn't), but personally, I think this is acceptable for a first run at orgs. Adnan Maolood Details Message ID In-Reply-To (view parent) DKIM signature pass Download raw message 5 hours ago On Mon Mar 13, 2023 at 10:59 AM EDT, Drew DeVault wrote: > The lack of a prefix may cause some conflicts with internal SourceHut > routes; we will have to audit them to understand the severity of this > conflict. It might be best to use a prefix for organizations as well as users to avoid this conflict. The prefix would need to be legal in both email addresses and URLs, and unescaped markdown. This prevents us from using ^, +, @, &, #, ?, $, *, and _. This leaves us with only a few options: - $ which can be annoying when using the shell - = and ! are usable, but not that elegant - ' and - which are small and hard to see In the end it might be better to use the same prefix "~" for both users and organizations. We would lose the ability to distinguish between users and organizations at a glance, but it spares us the burden of finding another suitable prefix. jman <~sircmpwn/sr.ht-discuss@city17.xyz> Details Message ID <87ilf4a5fe.fsf@city17.xyz> In-Reply-To (view parent) DKIM signature pass Download raw message 4 hours ago Hey, great to see starting a discussion about organizations! > Organizations are named without a prefix (differs from previous proposal > a few years back). I am "~sircmpwn" and I am a member of the "sourcehut" > organization. Some examples of resources owned by orgs: > > git.sr.ht/sourcehut/todo.sr.ht > sr.ht/sourcehut/sourcehut > sourcehut/discuss@lists.sr.ht > sourcehut.srht.site Ok, so resources of an organization can be defined as: - code repositories (git, hg) - mailing lists - ticketing systems - static websites - other? > All members are a member of the organization itself (simply sourcehut), > but may also be a member of any number of teams or sub-teams. Sub-teams > do not inherit the members of their parent team or vice-versa; they are > simply a means of namespacing members per the needs of each org. If org. members /must not/ belong to teams, permissions for members are freely decided by the organization, right? One organization can choose to be completely flat and assign permissions without creating a hierarchy of teams or splitting roles to access its resources. Correct? > Up to some percentage of the membership of an organization (say, for the > sake of argument, 50%) must have a paid SourceHut account, either > directly or through financial aid. Users can form grassroots > organizations on SourceHut so long as a sufficient number of them have > paid accounts, with no further fanfare regarding billing. The ratio of paying vs. non-paying members will be decided by the organization itself or by Sourcehut? > Additionally, organizations may have their own billing information > associated with the org itself. I'll try to rephrase the member/organization billing to check my understading. Organizations in Sourcehut will pay for the service on a per user basis ("seat"). If they have 10 users under their umbrella, they will pay 10 seats to Sourcehut (a la Github). Organizations can decide to sponsor some users and let them join the organization for free. The organization will simply buy an additional "seat" and assign it for free to the user. Existing paying Sourcehut users can also join an organization at no additional cost for the organization (what Github calls "outside collaborators"). When I want to join an organization, the Sourcehut UI will somehow show the organization if I am already a paying member. A paying Sourcehut user joining an organization will not take a "seat" from those assigned to the organization (like you mention down in the document). Is that all correct? > An emergent behavior of this system is that a user who is a member of > several organizations can have their account sponsored by one of them > and then have their paid account contribute to the 50% threshold of > _all_ of them. The politics of who pays for whose account is not my > problem, thank you, good luck sorting that out. When a paying or sponsored Sourcehut user asks to join an organization, the UI will show if that account billing is being covered, no need to tell who is paying for that account and how much the aspiring member is paying. The difference with Github will be that a paying Sourcehut user will not use a paid "seat" license of the organization. > Open question as to how to structure user's access to their org > resources via the API. Should we have special OAuth tokens which grant > access to the org resources? (probably not -- existing user credentials > may be enough?) Will have to do a separate draft of some GraphQL > changes. Do org. members access all or none organization resources? Probably we want a matrix of resources and who can access to what. In any case I would implement a token-handing system that allows assigning fine r/w access to the organization resources. This will come in handy if the organization wants to kick out a user. Tokens should also have an expiry, users will be responsible to regenerate them. When a user is kicked out from the organization, the users' tokens will expire immediately and the user won't be allowed to generate more tokens to access the organization resources. Another thing I'd probably implement from day one is a flag that makes obligatory for organization members to have 2FA enabled for their own account. ~jman Details Message ID <87r0ts8qpd.fsf@city17.xyz> In-Reply-To (view parent) DKIM signature pass Download raw message 4 hours ago > In the end it might be better to use the same prefix "~" for both users > and organizations. We would lose the ability to distinguish between > users and organizations at a glance, but it spares us the burden of > finding another suitable prefix. If a prefix needs to be used, I agree to keep the existing "~". It's ugly but at least it's consistent. By the way, I never understood (or just forgot) the reasoning behind that prefix for Sourcehut usernames. Moritz Poldrack Details Message ID In-Reply-To <87r0ts8qpd.fsf@city17.xyz> (view parent) DKIM signature pass Download raw message 4 hours ago On Mon Mar 13, 2023 at 7:10 PM CET, ~jman wrote: > By the way, I never understood (or just forgot) the reasoning behind > that prefix for Sourcehut usernames. My guess would be the old notation for UNIX user accounts. cd ~ftp brings you to the home of the ftp user for example. -- Moritz Poldrack https://moritz.sh Kurt H Maier Details Message ID In-Reply-To (view parent) DKIM signature pass Download raw message 2 hours ago One of the advantages of organizations here is reducing the bus factor for operational matters. If a group member is using their account credentials to e.g. run CI/CD, and that group member is for any reason unavailable, what's the plan for the rest of the group to make needed changes? With an org-specific credential which members can access, other users can step in to mitigate problems. If everyone is using their own creds for API access, that collaboration gets harder. To be clear: I'm not an expert in SourceHut architecture. I'm asking these questions because I don't know the answer, not out of some Socratic drive to make a point in the mind of the reader. Thanks, khm Reply to thread Export thread (mbox) Forward this thread to me