I've been thinking about how to design user groups (aka organizations)
on SourceHut, and I'd like your input. What kinds of structures would be
beneficial for your project? Would this design suit your needs?

    Functionality

User groups will use the ^ prefix, similar to today's ~ prefix for
users, and will be able to own resources across the site. For example,
"git.sr.ht/^sourcehut/core.sr.ht".

Group membership is divided into subgroups. All users in the SourceHut
group would be a member of ^sourcehut, and by default there would be an
additional subset called ^sourcehut/admins which defines who can modify
group membership. The admins subgroup cannot be removed, but other user
groups can be added by admins as necessary. These groups can be fed into
access control lists throughout the site as a shorthand for a group of
people, e.g. ^sourcehut/todo/committers or ^sourcehut/staff. A user can
be a member of any number of groups and subgroups.

At first, only admins will be able to create new resources (like
repositories) on behalf of the user group. In the future, it might be
useful to expand the number of rights which admins can delegate to other
groups.

    Payment

I'm open to suggestions here, but here's the general plan:

Organizations will be able to sponsor the accounts of their members.
They can also have members who have paid for their own account
participate in the group without an additional charge.

To sponsor accounts, user groups will be able to pay for a certain
number of seats. The first 5 seats will be name your price (like normal
accounts). The next 20 seats will be limited to the second and third
pricing tiers. Any additional seats will be required to use the third,
and highest, pricing tier. This is a progressive system - your 26th user
will cost $10/mo or $100/year, but it will not change the price you're
already paying for the first 25 seats.

As usual, participation from external contributors with or without an
account will always be supported for free. However, to be a member of
the group, the user will have to pay for their account or receive a
sponsorship from an organization.

    API access

For now, API access won't be affected in any special way - anything you
can do on the web, you can do with the API. In the future, I would like
to add more fine-grained API access controls for OAuth clients in
general, so you can for example choose only a subset of your git
repositories to offer to third-party applications. When this overhaul
takes place, it might make sense to revisit the interaction between the
API and user groups.

    Migration plan

I plan on making it possible to move any resources (repos, mailing
lists, and so on) which you already have on a user account to a group
account, if you so desire.

On Thu, Feb 13, 2020, at 13:10, Drew DeVault wrote:
>     Functionality
> 
> User groups will use the ^ prefix, similar to today's ~ prefix for
> users, and will be able to own resources across the site. For example,
> "git.sr.ht/^sourcehut/core.sr.ht".

A thought here - I don't know if this thought is a good thing or a bad
thing in general. If someone is coming from outside the SourceHut
world, this is leaking implementation details. Why should someone need
to know whether a git repo is owned by a group or a user?

It seems like it may be confusing, again for those who aren't spending
time in SourceHut-world. Some repos I want to clone are ^-repos and
some are ~-repos.


> At first, only admins will be able to create new resources (like
> repositories) on behalf of the user group. In the future, it might be
> useful to expand the number of rights which admins can delegate to other
> groups.

On this front, I think something that's going to need clarification
quickly is how multi-membership composes. Do I get the union,
intersection, or most restrictive permissions of the multiple roles I
belong?

I actually find myself thinking of something almost like a pf.conf
with the ability to add users to groups (roughly equivalent to a macro
or table in pf.conf). Then you can define grant and deny rules based
(roughly, pass and block) for each permission. I say this coming from
many conversations with enterprise clients about permissions and
rights-management for a number of products I consult on. These
conversations tend to disappoint, because invariably they will have
some obscure requirement they insist is business critical that doesn't
map onto the security functionality of the product.

As I type it out, it feels like overkill, and perhaps it would be
better to have a more streamlined rights-management strategy like
"union of all role permissions" and just dealing with it that way.


> access control lists throughout the site as a shorthand for a group of
> people, e.g. ^sourcehut/todo/committers or ^sourcehut/staff. A user can
> be a member of any number of groups and subgroups.

Finally, looking at this, I find myself wondering if it makes sense to
build hierarchies. E.g. ^sourcehut/staff/sub/roles. There could be
some set of permissions for all staff, and then different sub-groups
have differing permissions for different components.


I'll restate that all of these are more questions at this point than
suggestions.

-gb

I’ve got two comments on the pricing model, which are less about what 
I want, and more just business experience from my past ventures.

On 13 Feb 2020, at 13:10, Drew DeVault wrote:

>     Payment
>
> I'm open to suggestions here, but here's the general plan:
>
> Organizations will be able to sponsor the accounts of their members.
> They can also have members who have paid for their own account
> participate in the group without an additional charge.

This doesn’t make much sense to me, from two angles.

First, you’re setting yourself up for needlessly high churn.  Say Sue 
is a paying member of Sourcehut, and joins a company with a corporate 
Sourcehut account.  She’ll statistically cancel her account to save 
the few bucks a month, because the account will be paid for by her 
employer.  When she then leaves, she now has to actively sign up 
again--and sometimes, she won’t, even if she would never have canceled 
otherwise in the first place.  Maybe the free tier is good enough, maybe 
she decides to try GitHub for awhile, it varies.  At any rate, this kind 
of flow, from experience, is a great way to lose happy paying customers 
for no real reason.

Second, you’re leaving money on the ground from the organizations.  
Whether initially or not, you’re going to be looking at features that 
make sense for organizations, but not for individuals.  With the pricing 
model you’re proposing, you’re not only not charging organizations 
for those features; you’re actually giving companies a *discount* to 
use Sourcehut, proportional to how many of their employees are paying on 
an individual basis.  That seems counterintuitive.

I get what you’re aiming for here, but doing something more 
orthogonal, like e.g. Trello’s distinction between Gold (paid for by 
individuals) and Business Class (paid for by organization), would 
probably result in a larger and (more importantly for Sourcehut’s 
health) steadier revenue stream.

>
> To sponsor accounts, user groups will be able to pay for a certain
> number of seats. The first 5 seats will be name your price (like 
> normal
> accounts). The next 20 seats will be limited to the second and third
> pricing tiers. Any additional seats will be required to use the third,
> and highest, pricing tier. This is a progressive system - your 26th 
> user
> will cost $10/mo or $100/year, but it will not change the price you're
> already paying for the first 25 seats.

This is *fair*, and I wish this model worked, but in my experience, it 
backfires horribly.  I have worked at a company that did per-seat 
pricing before, and people game the living daylights out of it.  Five 
devs on one account, close accounts any month you think you can get away 
with it, etc., just to save a few bucks here or there.  Ignoring lost 
revenue, it also inflates churn and makes them likelier to leave (see 
above).  Making the per-seat pricing progressive will rapidly compound 
that, since you’re providing extra disincentives for the sixth, 21st, 
and so on tiers.  This will all combine to artificially suppress your 
paid seats.  (And it also doesn’t help that you’re making it cheaper 
for a company to pay individuals to sign up for personal accounts, 
rather than sponsoring accounts.)

Tiered buckets with feature bumps help a ton here.  E.g., $100/mo for 
0-10 users with feature set $X, $500/mo for 11-50 users which also gets 
you feature set $Y, $1250 for 50-100 plus you get additional feature $Z 
in addition to $X + $Y, etc.  This decreases the incentive to drop back 
a tier when you drop under the threshold, and gives some incentive to 
upgrade preemptively to get the extra features.

Anyway, these are just some thoughts.  I really like that you’re not 
tiering any of the features right now, and I’d absolutely respect you 
sticking to your guns on that.  But I wanted to flag that the pricing 
model you’ve got is likely to result in much lower revenue and much 
higher churn than some other options, so you were at least making that 
decision aware of the trade-offs.

--Benjamin

Hello Drew!

Thank you for giving us a chance to provide some feedback!

> User groups will use the ^ prefix, similar to today's ~ prefix

I like the fact that I would be able to instantaneously tell whether
a repository belongs to an organization or to a user.

> Group membership is divided into subgroups. […] by default
> there would be an additional subset called ^sourcehut/admins
> which defines who can modify group membership. […] other
> user groups can be added by admins as necessary. These
> groups can be fed into access control lists […]

Perfectly happy with this, although I would suggest renaming 
“groups” into “organizations” and “subgroups” to “groups” or 
“teams”.

> I plan on making it possible to move any resources (repos, mailing
> lists, and so on) which you already have on a user account to a group
> account, if you so desire.

Much appreciated.

> The next 20 seats will be limited to the second and third
> pricing tiers. Any additional seats will be required to use the third,
> and highest, pricing tier.

I suspect this might scare off larger organizations as I think 
the expectation is for per-seat pricing to decrease as the number
of seats increases, particularly if paid yearly.

My two cents,
Jacopo.

---

Jacopo Scazzosi
https://keybase.io/jacoscaz



>    Functionality
> 
> 
> 
> 
> At first, only admins will be able to create new resources (like
> repositories) on behalf of the user group. In the future, it might be
> useful to expand the number of rights which admins can delegate to other
> groups.
> 
>    Payment
> 
> I'm open to suggestions here, but here's the general plan:
> 
> Organizations will be able to sponsor the accounts of their members.
> They can also have members who have paid for their own account
> participate in the group without an additional charge.
> 
> To sponsor accounts, user groups will be able to pay for a certain
> number of seats. The first 5 seats will be name your price (like normal
> accounts). The next 20 seats will be limited to the second and third
> pricing tiers. Any additional seats will be required to use the third,
> and highest, pricing tier. This is a progressive system - your 26th user
> will cost $10/mo or $100/year, but it will not change the price you're
> already paying for the first 25 seats.
> 
> As usual, participation from external contributors with or without an
> account will always be supported for free. However, to be a member of
> the group, the user will have to pay for their account or receive a
> sponsorship from an organization.
> 
>    API access
> 
> For now, API access won't be affected in any special way - anything you
> can do on the web, you can do with the API. In the future, I would like
> to add more fine-grained API access controls for OAuth clients in
> general, so you can for example choose only a subset of your git
> repositories to offer to third-party applications. When this overhaul
> takes place, it might make sense to revisit the interaction between the
> API and user groups.
> 
>    Migration plan
> 
> I plan on making it possible to move any resources (repos, mailing
> lists, and so on) which you already have on a user account to a group
> account, if you so desire.

Am 13. Februar 2020 19:10:55 MEZ schrieb Drew DeVault <sir@cmpwn.com>:
>I've been thinking about how to design user groups (aka organizations)
>on SourceHut, and I'd like your input. What kinds of structures would
>be
>beneficial for your project? Would this design suit your needs?
>
>    Functionality
>
>User groups will use the ^ prefix, similar to today's ~ prefix for
>users, and will be able to own resources across the site. For example,
>"git.sr.ht/^sourcehut/core.sr.ht".
>
>Group membership is divided into subgroups. All users in the SourceHut
>group would be a member of ^sourcehut, and by default there would be an
>additional subset called ^sourcehut/admins which defines who can modify
>group membership. The admins subgroup cannot be removed, but other user
>groups can be added by admins as necessary. These groups can be fed
>into
>access control lists throughout the site as a shorthand for a group of
>people, e.g. ^sourcehut/todo/committers or ^sourcehut/staff. A user can
>be a member of any number of groups and subgroups.
>
>At first, only admins will be able to create new resources (like
>repositories) on behalf of the user group. In the future, it might be
>useful to expand the number of rights which admins can delegate to
>other
>groups.
>
>    Payment
>
>I'm open to suggestions here, but here's the general plan:
>
>Organizations will be able to sponsor the accounts of their members.
>They can also have members who have paid for their own account
>participate in the group without an additional charge.
>
>To sponsor accounts, user groups will be able to pay for a certain
>number of seats. The first 5 seats will be name your price (like normal
>accounts). The next 20 seats will be limited to the second and third
>pricing tiers. Any additional seats will be required to use the third,
>and highest, pricing tier. This is a progressive system - your 26th
>user
>will cost $10/mo or $100/year, but it will not change the price you're
>already paying for the first 25 seats.
>
>As usual, participation from external contributors with or without an
>account will always be supported for free. However, to be a member of
>the group, the user will have to pay for their account or receive a
>sponsorship from an organization.
>
>    API access
>
>For now, API access won't be affected in any special way - anything you
>can do on the web, you can do with the API. In the future, I would like
>to add more fine-grained API access controls for OAuth clients in
>general, so you can for example choose only a subset of your git
>repositories to offer to third-party applications. When this overhaul
>takes place, it might make sense to revisit the interaction between the
>API and user groups.
>
>    Migration plan
>
>I plan on making it possible to move any resources (repos, mailing
>lists, and so on) which you already have on a user account to a group
>account, if you so desire.

I'm looking forward to user groups on sourcehut!

One minor note though: using ^ as the sigil to denote might cause some unnecessary confusion for zsh users when using the url to a user group or one of its repositories / lists /... on the command line as zsh interprets unquoted strings containing a ^ as some kind of glob.

Maybe a different sigil like + could be used?

On Fri Feb 14, 2020 at 12:56 PM, Jonas Platte wrote:
> I'm looking forward to user groups on sourcehut!
>
> One minor note though: using ^ as the sigil to denote might cause some
> unnecessary confusion for zsh users when using the url to a user group
> or one of its repositories / lists /... on the command line as zsh
> interprets unquoted strings containing a ^ as some kind of glob.
>
> Maybe a different sigil like + could be used?

As a zsh user, I think just escaping the ^ would be sufficient.
That being said, according to RFC 3986 (https://tools.ietf.org/html/rfc3986#section-3.3)
the only valid characters in a URI are:

> a-z A-Z 0-9 . - _ ~ ! $ & ' ( ) * + , ; = : @

^ is not a valid character in a URL path, but + is.
So while the zsh globbing argument isn't really an issue IMO, potentially
having non-URI safe characters on Sourcehut is.

This is, of course, not a problem if the intent is not to have the ^ as
part of the URIs, but I think it's safe to assume that was the intent as
that is how user's are currently handled.

--Noah

On Thu, Feb 13, 2020, at 13:10, Drew DeVault wrote:
> User groups will use the ^ prefix, similar to today's ~ prefix for
> users, and will be able to own resources across the site. For example,
> "git.sr.ht/^sourcehut/core.sr.ht".

I understand the need for some sort of prefix so that someone doesn't
register the org "about" and now you can never make a page called
git.sr.ht/about and all the handlers get confused, etc. but in general I
wish this would be a path for a slightly silly, but surprisingly
constant annoyance I run into:

When trying to find a repo in my history, or using autocomplete in the
address bar (I can never remember how sircmpwn is spelled off the top of
my head, for example) I have to type the ~ before autocomplete works
(eg. git.sr.ht/~s). While this sounds silly, it's in an odd place on my
keyboard (and generally every keyboard layout I've ever used for that
matter) and I frequently stumble over it.

Also, with organizations I suspect branding would be more important than
with a personal account, and I wouldn't want my users being confused
(even briefly) about why the code was stored under ^example when my
companies logo is stylized differently and doesn't have the odd caret.

Both minor nits, but the prefix is one of the few things I don't
especially care for in sr.ht land, personally, I'd prefer just
"git.sr.ht/orgs/example" or something similar.

Alternatively, a feature request: it would be nice to be able to CNAME
code.example.net to sr.ht/^example or similar and have it serve things
in the future, although I can imagine this would make auth trickier. It
would fix the branding issue though if I don't want to host my own.

—Sam

On Fri Feb 14, 2020 at 10:15 AM, Sam Whited wrote:
> When trying to find a repo in my history, or using autocomplete in the
> address bar (I can never remember how sircmpwn is spelled off the top of
> my head, for example) I have to type the ~ before autocomplete works
> (eg. git.sr.ht/~s). While this sounds silly, it's in an odd place on my
> keyboard (and generally every keyboard layout I've ever used for that
> matter) and I frequently stumble over it.

I think you should report this bug to your web browser.

> Alternatively, a feature request: it would be nice to be able to CNAME
> code.example.net to sr.ht/^example or similar and have it serve things
> in the future, although I can imagine this would make auth trickier. It
> would fix the branding issue though if I don't want to host my own.

This has been raised before, it's complicated. I'm not necessarily
against it.

On Fri, Feb 14, 2020, at 10:16, Drew DeVault wrote:
> I think you should report this bug to your web browser.

It's not a bug, I don't want it showing me a giant autocomplete list
because if I type git.sr.ht/s it shows everything with an s anywhere
in the URL. That would be just about impossible to navigate.

—Sam


-- 
Sam Whited

Regarding all of the comments about the ^ prefix, would a ! prefix be
better? I definitely want a prefix. I don't want to bikeshed over "it
looks weird", but arguments like the zsh one are better.

On Fri Feb 14, 2020 at 11:22 AM, Jacopo Scazzosi wrote:
> Perfectly happy with this, although I would suggest renaming “groups”
> into “organizations” and “subgroups” to “groups” or “teams”.

I chose groups to align more closely with Unix terminology, which is the
same reason users are ~ and usernames must be valid Unix usernames. I
also don't want to blithely rip off GitHub.

> I suspect this might scare off larger organizations as I think the
> expectation is for per-seat pricing to decrease as the number of seats
> increases, particularly if paid yearly.

The goal is to not charge small open source organizations more than they
can afford, or to make it so you have to have a budget before you can
host your project on SourceHut. This is also why groups can have their
members pay for their own account, so that groups of paid users can
organize for free. The prices are cranked up slowly for the purpose of
subsidizing the costs of small projects with the resources of larger
projects, which is also done on an individual scale by using the
collective paid userbase to help subsidize students or anyone who
otherwise cannot afford their account.

That being said, the subtleties here are really difficult. I'm
definitely going to put more thought into the payment model for
organizations. It's difficult to make sure that orgs which can pay, are
paying, and orgs which can't pay, are not excluded.

On Thu Feb 13, 2020 at 8:50 PM, Benjamin Pollack wrote:
> First, you’re setting yourself up for needlessly high churn. Say Sue
> is a paying member of Sourcehut, and joins a company with a corporate
> Sourcehut account. She’ll statistically cancel her account to save
> the few bucks a month, because the account will be paid for by her
> employer. When she then leaves, she now has to actively sign up
> again--and sometimes, she won’t, even if she would never have canceled
> otherwise in the first place. Maybe the free tier is good enough, maybe
> she decides to try GitHub for awhile, it varies. At any rate, this kind
> of flow, from experience, is a great way to lose happy paying customers
> for no real reason.

Aye, this is a valid concern. I definitely want groups of paid users to
be able to self-organize for free, and I definitely want orgs to be able
to pay the fees for their members. Finding a balance will be
challenging.

> I get what you’re aiming for here, but doing something more
> orthogonal, like e.g. Trello’s distinction between Gold (paid for by
> individuals) and Business Class (paid for by organization), would
> probably result in a larger and (more importantly for Sourcehut’s
> health) steadier revenue stream.

I also want to be careful about limiting feature access to different
tiers of payment. I know that it makes sense from a purely financial
standpoint, but it doesn't sit well with me from a values standpoint.

> This is *fair*, and I wish this model worked, but in my experience, it
> backfires horribly. I have worked at a company that did per-seat
> pricing before, and people game the living daylights out of it. Five
> devs on one account, close accounts any month you think you can get away
> with it, etc., just to save a few bucks here or there. Ignoring lost
> revenue, it also inflates churn and makes them likelier to leave (see
> above). Making the per-seat pricing progressive will rapidly compound
> that, since you’re providing extra disincentives for the sixth, 21st,
> and so on tiers. This will all combine to artificially suppress your
> paid seats. (And it also doesn’t help that you’re making it cheaper
> for a company to pay individuals to sign up for personal accounts,
> rather than sponsoring accounts.)

I can just make this kind of gaming behavior against the terms of
service, and enforce it. SourceHut is a collaboration between us and our
customers, not a traditional service per-se. The kind of organizations
which would try to game this are not the kind of customers I want to
work with anyway. The relationship we have is one of mutual respect and
cooperation.

I'm also totally fine with leaving money on the table. The mission
statement of SourceHut is "make free and open source software better",
not "extract value from FOSS communities". This isn't a purely
capitalist endeavour.

On Thu Feb 13, 2020 at 1:35 PM, Greg B wrote:
> A thought here - I don't know if this thought is a good thing or a bad
> thing in general. If someone is coming from outside the SourceHut
> world, this is leaking implementation details. Why should someone need
> to know whether a git repo is owned by a group or a user?

The implementation details matter, so leaking them doesn't bother me.
Others have given positive feedback for being able to tell orgs and
users apart at a glance.

> On this front, I think something that's going to need clarification
> quickly is how multi-membership composes. Do I get the union,
> intersection, or most restrictive permissions of the multiple roles I
> belong?

The plan is to let you do any combination of these. By default a
sub-group will inherit the permissions of its parent group, but it can
be given more or have some taken away.

> I actually find myself thinking of something almost like a pf.conf
> with the ability to add users to groups (roughly equivalent to a macro
> or table in pf.conf). Then you can define grant and deny rules based
> (roughly, pass and block) for each permission. I say this coming from
> many conversations with enterprise clients about permissions and
> rights-management for a number of products I consult on. These
> conversations tend to disappoint, because invariably they will have
> some obscure requirement they insist is business critical that doesn't
> map onto the security functionality of the product.

Yeah, this thought crossed my mind, too, but I want to keep it simple.
The last thing I want to do is have everyone writing JSON files to
define their access roles. It might be nice for some use-cases, but most
people aren't automating their org structure to the degree where it
makes sense - and a declarative solution can be built on top of the API
anyway, when someone who needs it shows up.

> Finally, looking at this, I find myself wondering if it makes sense to
> build hierarchies. E.g. ^sourcehut/staff/sub/roles. There could be
> some set of permissions for all staff, and then different sub-groups
> have differing permissions for different components.

Aye, this is the intention of this design.

On Thu, Feb 13, 2020, at 13:10, Drew DeVault wrote:
> Organizations will be able to sponsor the accounts of their members.
> They can also have members who have paid for their own account
> participate in the group without an additional charge.

While I love this idea on the surface, I wonder if this will lead to
smaller projects only accepting users who already pay as members
because they don't want to go over their 5 seat free limit. This would
put the burden back on the individual, not the project sponsor which
may or may not be okay. Maybe orgs could always be charged even if the
member is already paying, but members can still be sponsored by orgs
and not have to pay?

—Sam

On Fri Feb 14, 2020 at 10:54 AM, Sam Whited wrote:
> While I love this idea on the surface, I wonder if this will lead to
> smaller projects only accepting users who already pay as members
> because they don't want to go over their 5 seat free limit. This would
> put the burden back on the individual, not the project sponsor which
> may or may not be okay. Maybe orgs could always be charged even if the
> member is already paying, but members can still be sponsored by orgs
> and not have to pay?

I think having the option for either approach lets the problem be solved
by negotiating it between the individual and the project directly. Make
the tools flexible and allow humans to decide how to use them.

Plus, in the worst case, any individual who can't afford their account
can just email me and I'll give them free service - this is true even
without organizations.

On Fri, Feb 14, 2020, at 10:50, Drew DeVault wrote:
> On Thu Feb 13, 2020 at 1:35 PM, Greg B wrote:
> > A thought here - I don't know if this thought is a good thing or a
> > bad thing in general. If someone is coming from outside the
> > SourceHut world, this is leaking implementation details. Why
> > should someone need to know whether a git repo is owned by a group
> > or a user?
>
> The implementation details matter, so leaking them doesn't bother me.
> Others have given positive feedback for being able to tell orgs and
> users apart at a glance.

Another interesting downside here that I just thought of: If I move my
repos that I have in an existing account named after my org now, all my
repos change URLs and bookmarks and links and things may break. This can
be fixed to a certain extent with redirects, but it's still not ideal
that the URL changed since I don't know if all my tooling supports
redirects or not without additional configuration.

—Sam

-- 
Sam Whited

On Fri, Feb 14, 2020, at 10:39, Drew DeVault wrote:
> Regarding all of the comments about the ^ prefix, would a ! prefix be
> better? I definitely want a prefix. I don't want to bikeshed over "it
> looks weird", but arguments like the zsh one are better.

If a glyph is definitely part of the name, then I think the earlier
comment on valid URI characters should absolutely guide the choice of
glyph.

> a-z A-Z 0-9 . - _ ~ ! $ & ' ( ) * + , ; = : @

Of those, I think the following make the most sense:

=  This is the closest to two tildes stacked on each other.
+  Regex "1-or-many". Arithmetic "more".
*  Regex "many". I think the common interpretation as a wildcard and
   glob pattern is a point against this.

If you want to be especially clever, you could use parens as a leading
and trailing glyph. Parens group things. I think this is silly,
though.

-gb

On Fri Feb 14, 2020 at 10:57 AM, Sam Whited wrote:
> Another interesting downside here that I just thought of: If I move my
> repos that I have in an existing account named after my org now, all my
> repos change URLs and bookmarks and links and things may break. This can
> be fixed to a certain extent with redirects, but it's still not ideal
> that the URL changed since I don't know if all my tooling supports
> redirects or not without additional configuration.

This isn't a problem with the prefix character, it's just a problem of
moving repos around. And in any case, redirects will be set up.

On Fri Feb 14, 2020 at 10:57 AM, Greg B wrote:
> On Fri, Feb 14, 2020, at 10:39, Drew DeVault wrote:
> > Regarding all of the comments about the ^ prefix, would a ! prefix be
> > better? I definitely want a prefix. I don't want to bikeshed over "it
> > looks weird", but arguments like the zsh one are better.
>
> If a glyph is definitely part of the name, then I think the earlier
> comment on valid URI characters should absolutely guide the choice of
> glyph.
>
> > a-z A-Z 0-9 . - _ ~ ! $ & ' ( ) * + , ; = : @
>
> Of those, I think the following make the most sense:
>
> = This is the closest to two tildes stacked on each other.
> + Regex "1-or-many". Arithmetic "more".
> * Regex "many". I think the common interpretation as a wildcard and
> glob pattern is a point against this.

We also need to limit to valid characters in an email address:

!#$%&'*+-/=?^_`{|}~

But note that we can URL-encode any character for use in a URL. Less
than ideal, but the option is there. The union of URL-valid and
email-valid characters is:

.-_~!&*+=

On Fri, Feb 14, 2020, at 10:58, Drew DeVault wrote:
> This isn't a problem with the prefix character, it's just a problem of
> moving repos around. And in any case, redirects will be set up.

I'm saying that if the prefix were the same for groups, you wouldn't
*have* to move repos around, you could just upgrade the user to a group.
Of course, some people would still want to move repos around but it may
also make it easier to transition to a group later if you started out as
a user, which seems like a big benefit to me (even with redirects, I
still hate to have to go update links everywhere).

—Sam

-- 
Sam Whited

On Fri Feb 14, 2020 at 11:01 AM, Sam Whited wrote:
> I'm saying that if the prefix were the same for groups, you wouldn't
> *have* to move repos around, you could just upgrade the user to a group.

Oh gosh, the logistics of this change aren't something I even want to
think about. Users will not become groups.

@all

From a discussion on IRC going over the options for the group prefix
character, the currently favored choice is +. Some examples:

Repo name:
	git.sr.ht/+sourcehut/meta.sr.ht

Mailing list address:
	+sourcehut/devel@lists.sr.ht

ACL:
	+sourcehut/committers/meta.sr.ht

Ticket mention:
	Can we get +sourcehut/staff to comment on this?

Thanks for the write-up and discucssion!

> From a discussion on IRC going over the options for the group prefix
> character, the currently favored choice is +. Some examples:

This looks a lot better than ^, which I really didn't like. I don't
know why we need a prefix though. The absence of a tilde is enough to
tell it's not a user. And if the parallel with Unix is what we're
shooting for, in Unix users have the tilde prefix, but groups don't
have any prefix.

The only point of a having a prefix for groups is if you have plans to
have a *third* "thing" later down the line, and we need to
differentiate between all three (although even then, 2 could have
prefixes and the 3rd doesn't).

In case this applies, remember that some email providers like Gmail do
some funky stupid stuff with "+", effectively ignoring everything that
comes after... but I don't think they do anything when *sending*
messages to an address with a "+" so that should be OK.

> Organizations will be able to sponsor the accounts of their members.
> They can also have members who have paid for their own account
> participate in the group without an additional charge.

I agree with Benjamin's comments there, but I'd add that you might want
to just... not do anything at first. It's easier to add discounts and
pricing options later, than to start with them and correct them while
people are already paying.

It's probably easier to make groups a thing that's separate from user
plans... as in: whether someone uses the free or paying versions of
groups has to do with access to group features (whatever they will be,
like advanced ACL and private mailing lists and whatever), and doesn't
(at first) concern user account in any way.

> On Thu Feb 13, 2020 at 1:35 PM, Greg B wrote:
> > this is leaking implementation details. Why should someone need
> > to know whether a git repo is owned by a group or a user?
> 
> The implementation details matter, so leaking them doesn't bother me.

This begs the question, "To whom do they matter?"

Ultimately, this is your project, and if you want a glyph for groups,
that is your call, and I will trust you that it matters to be exposed
as such. I must admit, though, that it is not apparent to me why this
matters in a way that needs to be exposed in the format of the
names. What is the reasoning that suggests it needs to be exposed? I
feel like I'm missing something based on being one of few people in
this thread questioning a hard delineation of users and groups in the
name.

I love implementation details. I love the guts of software and how
stuff works. But who is the name format primarily for? There is plenty
of software that can handle names being bound to a person or to some
logical grouping thereof.

A mailing list address is not of a different format than that for an
individual. Most programming languages do not have different
syntax for variables representing scalars and those
representing collections.

It seems to me that a name is a way to address things or people. From
several perspectives, it seems not to matter whether I am addressing
an individual or a group.

- I am strictly a consumer of some code hosted on SourceHut. I am not
  deeply familiar with the platform or its norms. I just care about
  getting to that sweet, sweet code. I don't particlularly care about
  whether a group of people maintain it as a formal group, or whether
  it is owned by an individual member. The org structure cannot even
  inform me of whether this is primarily maintained by one person or
  an actual group of multiple people. If I only ever copy/paste links,
  I probably don't much care. If I use multiple pieces of code from
  SourceHut, I probably encounter friction, because I don't know when
  to use a tilde or a $group_glyph (again, because I am not familiar
  with SourceHut). (Note: I am not suggesting here that people should
  choose to remain ignorant.) From this perspective, there is no
  benefit to a glyph to me. If I want to communicate, I send a mail to
  a list (which is a group by definition). If I want to raise an
  issue, I deal with a todo - I don't care who owns it; I just care
  that it is associated with a project.

- I am familiar with SourceHut, and perhaps I either regularly
  contribute to some project or host my own work here, so I know that
  there are two glyph-delineated namespaces. I've heard about a new
  project and I want to go check it out. I know the name of the
  project, but I didn't catch whether it was owned by a group or an
  individual. So I try both. It's not the end of the world, but my
  question is, again, why do I need to know. As a maintainer or
  contributor, I care what the name of my relevant projects are. And
  I'll know for each whether they are owned by an individual or a
  group. But I don't know why I care, or why I need to know that. It
  seems the definition of trivial, but I like SourceHut, or I like a
  project that is hosted here, so I put up with this. It's never a
  dealbreaker, but I don't know why it matters.

I can go down many of these paths and I don't often find myself
caring.

The obvious scenario where it matters to me is if I'm implementing
this. As an implementer of SourceHut, I absolutely care and need to
know at all times (or at least many times) whether this is the name of
group or an individual. This is probably one of the first conditionals
in many codepaths. I get this, and I do not mean to trivialize it.

Knowing whether something is owned by a group or an individual tells
me nothing of interest about that thing. It provides me effectively
zero context. It seems useful only if I need to make decisions based
on it, but I don't see it informing many decisions other than what
branch to take in code.

But I am left with the question I started with. To whom does this
implementation detail matter? The only answer I can come up with (this
is explicitly not equivalent to claiming that it's the only answer) is
that it matters to implementers, but not much to others. So I'm left
with my second question. What am I missing here that makes it
important to me as not-a-developer-of-SourceHut? I'll note that one
entirely valid response (out of many) is "SourceHut is a product first
and foremost for its developers." This is the stance OpenBSD takes and
that's great for that project. It's exactly what its developers want
it to be. I have not gotten a similar vibe from Drew or the marketing
around SourceHut. Perhaps I am misinterpreting?

-gb

Sorry for the brief reply, but in the middle of something. In short: it
matters because, to me, there is no one who is not an implementor of
SourceHut. When you find a bug in a FOSS project, I expect you to go fix
it. This is the primary advantage of free software. We are all SourceHut
users, and developers.

I think the + or the = are both good characters to use. I though Ludovic 
brought up a good point about the usage of + in at least Gmail. If + is 
a summation of users, then = could be united users for a common goal, if 
we wanted some sort of dumb meaning associated with the character. 
Either or I am happy with.

Tristan Partin

On Friday, February 14, 2020 11:36:25 AM EST Greg B wrote:
> Knowing whether something is owned by a group or an individual tells
> me nothing of interest about that thing. It provides me effectively
> zero context. It seems useful only if I need to make decisions based
> on it, but I don't see it informing many decisions other than what
> branch to take in code.
> 
> But I am left with the question I started with. To whom does this
> implementation detail matter? The only answer I can come up with (this
> is explicitly not equivalent to claiming that it's the only answer) is
> that it matters to implementers, but not much to others. So I'm left
> with my second question. What am I missing here that makes it
> important to me as not-a-developer-of-SourceHut?

As a consumer of a repositories from a code forge, I care.

It's common to see repositories that belong to an organization and where the 
organization posts the canonical version of that repository.

Frequently, individual contributors (who may or may not also be members of 
that organization) also post copies of the repository under their individual 
accounts for work on new features. Or just to have a version they control.

I have, on more than one occasion, wished that other forges made it easy to 
distinguish which copy is canonical just by looking at the URL.

It's quite appealing to me to have that flag in there.

(And yes, I see that the same problem could emerge when more than one org 
hosts a copy of a repository, but that is not anything I've ever spent time 
needing to disambiguate, whereas I have more than once had to spend a few 
minutes digging around to make sure I'm getting the right repo from 'hub or 
'lab.)

On Fri, Feb 14, 2020, at 11:39, Drew DeVault wrote:
> it matters because, to me, there is no one who is not an implementor of
> SourceHut. When you find a bug in a FOSS project, I expect you to go fix
> it. This is the primary advantage of free software. We are all SourceHut
> users, and developers.

I appreciate the clarification. I don't think it's too short at
all. It answers exactly why it matters.

I agree with your points, but tend not to frame things in that way - I
do have a fairly firm line in my head between "users" and
"developers". Much of my professional work is of a sort and in
environments where this line exists and user-friendly is almost always
prioritized over developer-friendly. I shouldn't just assume that
applies everywhere. (:

Thanks for helping me see!

-gb

W dniu 14.02.2020 o 17:31, Ludovic Chabant pisze:> [...] I don't
> know why we need a prefix though. The absence of a tilde is enough to
> tell it's not a user. And if the parallel with Unix is what we're
> shooting for, in Unix users have the tilde prefix, but groups don't
> have any prefix.

I know two places in unix in which you can put both a user and a grup,
and since they can have the same name, you need to disambiguate with a prefix:
- in chown, you specify groups as :mygroup
- in /etc/security/limits.conf, you specify groups as @mygroup

> The only point of a having a prefix for groups is if you have plans to
> have a *third* "thing" later down the line, and we need to
> differentiate between all three (although even then, 2 could have
> prefixes and the 3rd doesn't).

There already is a third thing: special urls, like /create/ or /api/.

> > The only point of a having a prefix for groups is if you have plans
> > to
> > have a *third* "thing" later down the line, and we need to
> > differentiate between all three (although even then, 2 could have
> > prefixes and the 3rd doesn't).
> 
> There already is a third thing: special urls, like /create/ or /api/.
Seconding this. Too many websites have no differentiation between
arbitraty resource URLs created by users and special URLs to perform
actions on the website. What happens if someone names their group
"create"? There's already https://git.sr.ht/create.... -ben

> On Feb 15, 2020, at 2:04, Greg B <g@greggyb.com> wrote:
> 
>  I
> do have a fairly firm line in my head between "users" and
> "developers". Much of my professional work is of a sort and in
> environments where this line exists and user-friendly is almost always
> prioritized over developer-friendly. I shouldn't just assume that
> applies everywhere. (:

In the perspective of free software, the difference between user and developer is a difference of degree, not a difference of essence, not only because users do what they can to help, but also because developing is one of the multiple possible ways to use the software.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

> On 15 Feb 2020, at 3:06 am, Drew DeVault <sir@cmpwn.com> wrote:
> 
> @all
> 
>> From a discussion on IRC going over the options for the group prefix
> character, the currently favored choice is +. Some examples:
> 
> Repo name:
> 	git.sr.ht/+sourcehut/meta.sr.ht
> 
> Mailing list address:
> 	+sourcehut/devel@lists.sr.ht
> 
> ACL:
> 	+sourcehut/committers/meta.sr.ht
> 
> Ticket mention:
> 	Can we get +sourcehut/staff to comment on this?

I think + is the logical choice:

  - it’s diametrically opposite the ~ on most keyboards
  - it denotes a summation (apt for groups/orgs)
  - it’s a common enough character for most users
  - it conforms to the sr.ht aesthetic
  - it’s in the set of valid characters

On 15 Feb 2020, at 3:06 am, Drew DeVault <sir@cmpwn.com> wrote:
> From a discussion on IRC going over the options for the group prefix
> character, the currently favored choice is +. Some examples:
> 
> Repo name:
> 	git.sr.ht/+sourcehut/meta.sr.ht
> 
> Mailing list address:
> 	+sourcehut/devel@lists.sr.ht
> 
> ACL:
> 	+sourcehut/committers/meta.sr.ht
> 
> Ticket mention:
> 	Can we get +sourcehut/staff to comment on this?

I like the + prefix!

I wonder if groupnames are allowed to overlap with usernames? It could
cause some confusion if both the user ~example and the group +example
exist. Also, this could possibly be used for phishing as well. Imagine
the group +example hosts their code at git.sr.ht/+example/project. Now
an attacker could create git.sr.ht/~example/project, which looks the
same but contains malicious code.

W dniu 15.02.2020 o 11:33, Noah Loomans pisze:
> I wonder if groupnames are allowed to overlap with usernames? It could
> cause some confusion if both the user ~example and the group +example
> exist. Also, this could possibly be used for phishing as well. Imagine
> the group +example hosts their code at git.sr.ht/+example/project. Now
> an attacker could create git.sr.ht/~example/project, which looks the
> same but contains malicious code.
> 

Or they could create git.sr.ht/+examp1e/project
or git.sr.ht/+exarnple/project.

Depending on your font, these may be easily confusable with the original url.

On Saturday, February 15, 2020 11:49 AM, Wolf480pl <wolf480@interia.pl> wrote:

> W dniu 15.02.2020 o 11:33, Noah Loomans pisze:
>
> > I wonder if groupnames are allowed to overlap with usernames? It could
> > cause some confusion if both the user ~example and the group +example
> > exist. Also, this could possibly be used for phishing as well. Imagine
> > the group +example hosts their code at git.sr.ht/+example/project. Now
> > an attacker could create git.sr.ht/~example/project, which looks the
> > same but contains malicious code.
>
> Or they could creategit.sr.ht/+examp1e/project
> or git.sr.ht/+exarnple/project.
>
> Depending on your font, these may be easily confusable with the original url.

There's also git.sr.ht/+exаmple, which is different from
git.sr.ht/+example (Cyrillic "A").

Hello,

On Fri 14 Feb 2020 at 10:57AM -05, Greg B wrote:

> On Fri, Feb 14, 2020, at 10:39, Drew DeVault wrote:
>> Regarding all of the comments about the ^ prefix, would a ! prefix be
>> better? I definitely want a prefix. I don't want to bikeshed over "it
>> looks weird", but arguments like the zsh one are better.
>
> If a glyph is definitely part of the name, then I think the earlier
> comment on valid URI characters should absolutely guide the choice of
> glyph.
>
>> a-z A-Z 0-9 . - _ ~ ! $ & ' ( ) * + , ; = : @
>
> Of those, I think the following make the most sense:
>
> =  This is the closest to two tildes stacked on each other.
> +  Regex "1-or-many". Arithmetic "more".
> *  Regex "many". I think the common interpretation as a wildcard and
>    glob pattern is a point against this.

ISTM that = is better than + simply because + already has an established
meaning in e-mail addresses (using it to filter mail into subinboxes is
not Gmail-specific; IIRC it's in an RFC somewhere).

I don't think that the fact that this filtering usage has the + appear
in the middle of the address, whereas sr.ht would have it appear at the
beginning of the address, is a good counterargument.

-- 
Sean Whitton

But emails don't actually have any technical requirement to use + in any
particular way. It's an implementation detail of certain MTAs to
disregard +..., and it only applies it to incoming emails - it wouldn't
affect your ability to write emails to lists which use the + symbol in
the name (at least not any more than ~, for which we already have a
fallback).

Hello,

On Sat 15 Feb 2020 at 08:58PM -05, Drew DeVault wrote:

> But emails don't actually have any technical requirement to use + in any
> particular way. It's an implementation detail of certain MTAs to
> disregard +..., and it only applies it to incoming emails - it wouldn't
> affect your ability to write emails to lists which use the + symbol in
> the name (at least not any more than ~, for which we already have a
> fallback).

Right.  But it has that established meaning in people's minds so could
cause confusion.  "Wait a minute, don't pluses in e-mails mean that part
isn't really part of the address?"

-- 
Sean Whitton

On Sat, Feb 15, 2020 at 10:26:42PM -0700, Sean Whitton wrote:
> Right.  But it has that established meaning in people's minds so could
> cause confusion.  "Wait a minute, don't pluses in e-mails mean that part
> isn't really part of the address?"

This is much less likely to be the case when the plus is at the
beginning and what comes after is obviously meaningful.  What's more,
anyone familiar with the 'pluses in email addresses' convention is a
power user.  Power users should be able to learn new things and apply
critical thinking.

February 15, 2020 4:40 AM, "Drew DeVault" <sir@cmpwn.com> wrote:

> That being said, the subtleties here are really difficult. I'm
> definitely going to put more thought into the payment model for
> organizations.

As an individual user of SourceHut, I wouldn't want my personal SourceHut
account to subsidise my company's simultaneous use of SourceHut. I would
expect that my employer would pay for an employee's use of SourceHut
regardless of whether that employee already had their own personal account.
I think keeping the accounting separate is a benefit to both employer
and employee.

Why not consider a resource limit on organizations? Sure, there's some overhead to keep track of, but this allows for better flexibility between individuals and organizations, and may serve as a good basis for metric collection on the organization's side (git repo size, build bandwidth and time, dispatch calls, etc)

Resources keeps the model somewhat separate, where users pay for their account (which could be sponsored by an organization), and organizations would pay for usage, whether that's # of git repos, # of dispatch and builds per repo, and/or # of lists.
Sponsored organizations/projects could have a limit to these resources for "free", and it keeps introductory organization rates down for the bare minimum.

One random thought would be the ability for organizations to expand from a resource model to renting servers, where sourcehut staff could set up a dedicated sourcehut instance for the organization.

On 2/16/20 7:10 PM, Cosmo Borsky wrote
> Why not consider a resource limit on organizations? Sure, there's some overhead to keep track of, but this allows for better flexibility between individuals and organizations, and may serve as a good basis for metric collection on the organization's side (git repo size, build bandwidth and time, dispatch calls, etc)
>
> Resources keeps the model somewhat separate, where users pay for their account (which could be sponsored by an organization), and organizations would pay for usage, whether that's # of git repos, # of dispatch and builds per repo, and/or # of lists.
> Sponsored organizations/projects could have a limit to these resources for "free", and it keeps introductory organization rates down for the bare minimum.
Ooh, this is really interesting to me -- I find it easier to think about 
users and groups paying for largely distinct types of resources, and 
think it might be less confusing to users & groups looking at Sourcehut.

On Mon Feb 17, 2020 at 12:10 AM, Cosmo Borsky wrote:
> Why not consider a resource limit on organizations? Sure, there's some
> overhead to keep track of, but this allows for better flexibility
> between individuals and organizations, and may serve as a good basis for
> metric collection on the organization's side (git repo size, build
> bandwidth and time, dispatch calls, etc)
>
> Resources keeps the model somewhat separate, where users pay for their
> account (which could be sponsored by an organization), and organizations
> would pay for usage, whether that's # of git repos, # of dispatch and
> builds per repo, and/or # of lists.
>
> Sponsored organizations/projects could have a limit to these resources
> for "free", and it keeps introductory organization rates down for the
> bare minimum.

This is a good idea. Need to think about how to balance it for ad-hoc
organizations of users, which don't map onto real-life organizations
with a budget to pay for things like this, but it's a better model than
what I had in mind for sure.

> This is a good idea. Need to think about how to balance it for ad-hoc
> organizations of users, which don't map onto real-life organizations
> with a budget to pay for things like this, but it's a better model than
> what I had in mind for sure.

Are ad-hoc organizations expecting to use more resources than companies/larger orgs? My thinking behind this is that resources are sort of freely available to sourcehut users, where limits are on machine time and not exactly usage of resources (though I may be wrong, I have lurking for the better part of a year). If anything, SourceHut could sponsor organizations with more resources or a discounted/free rate.

Maybe adapting Migadu's tiers, where users are roughly limited by a resource (I.e. emails out per day), and if they hit that limit a courtesy notification would ask the user to upgrade to the next plan, and service would be cut back for the rest of the day if a % above the limit is hit.

A rough pricing model could be:
"Open Source" - organizations that strictly work on open source could be sponsored by SourceHut (similar to a user being sponsored by Drew), where they would have the same limits as the "introductory organization" tier. This group could also be used for ad hoc orgs, where it isn't one sole entity but a group of source hut users pooling a project together (eg. SourceHut itself).
"Introductory" - $25/mo, includes 3 SourceHut user sponsors, and offers 20 Git repos, 20G total Git storage, 50 dispatch events per day, and 20hrs of build time a week.
"Established" - $75/mo, 10 SourceHut user sponsors, unlimited Git repos and 100G total Git storage, 200 dispatch events per day, ...
"Organization" - $200/mo, 1tb total Git storage, 1000 dispatch events per day, 200hrs of build time, ...
"Dedicated" - $750/mo, dedicated SourceHut instance, includes support from SourceHut staff. Resources limited based on hardware chosen, upgraded or distributed hardware factors into the monthly price.