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.
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 <sir@cmpwn.com> 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.
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.
> On 13/03/2023 15:32 GMT Drew DeVault <sir@cmpwn.com> 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?
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.
Ingo Hoffmann <ingo@hoffmann.cx> 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.
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.
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.
> 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.
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
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
> 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.
The reasoning about reducing the bus factor makes sense, and (imo) this
is better achieved by simply having more people access the service.
Sharing credentials is orthogonal to this and probably dangerous. If
org-specific credentials leak or are compromised, everyone needs to get
new credentials. With member-specific credentials, just that one token
that was leaked needs to be rotated.
> This prevents us from using ^, +, @, &, #, ?, $, *, and _.> > This leaves us with only a few options:> > - $ which can be annoying when using the shell
According to your notes above, $ is not a legal option.
> - = and ! are usable, but not that elegant
! actually presents the same issue as $ on the shell, you'd have to
escape both of them.
> - ' and - which are small and hard to see
' is actually just as much of a pain because you'd still need to escape
it.
All in all, that leaves - and = out of the options you've presented.
I think I'm mostly okay with the lack of a prefix on organizations. It
makes the most sense so long as it doesn't cause any major issues
through conflict.
--
/*
* Ren Kararou
* PGP: B0BA4EEC0714F8E6
* Site: https://lesbianunix.dev
*/
"Adnan Maolood" <adnan@maolood.com> writes:
> 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.
What about using "~~" double prefix?
--
Ihor Radchenko // yantar92
> On 15/03/2023 08:48 GMT Ihor Radchenko <yantar92@posteo.net> wrote:> > > "Adnan Maolood" <adnan@maolood.com> writes:> > > 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.> > What about using "~~" double prefix?
That looks like a good idea.
On 15/03/2023 09:51, Ingo Hoffmann wrote:
> >> On 15/03/2023 08:48 GMT Ihor Radchenko <yantar92@posteo.net> wrote:>>>> >> "Adnan Maolood" <adnan@maolood.com> writes:>>>>> 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.>>>> What about using "~~" double prefix?> > That looks like a good idea.
I quite like this idea too -- clean and doesn't clobber the existing
username space.
--
B102 5976 C7F1 7230 008C FE0F E1A7 73D8 C2D0 9538
15 Mar 2023 09:48:02 Ihor Radchenko <yantar92@posteo.net>:
>> What about using "~~" double prefix?>
Not a big fan, to be honest. It looks weird and I am not too sure how
this would make routing easier. Personally, I'd prefer to not have a
prefix to mirror the UNIXy style currently prevalent across sourcehut
(~user, ls -l style file listing, …).
--
Moritz Poldrack
https://moritz.sh
On Wed, Mar 15, 2023 at 11:26:50AM +0100, Moritz Poldrack wrote:
> > What about using "~~" double prefix?> > Not a big fan, to be honest. It looks weird and I am not too sure how this> would make routing easier. Personally, I'd prefer to not have a prefix to> mirror the UNIXy style currently prevalent across sourcehut (~user, ls -l> style file listing, …).
I could not agree more. Despite of my understanding where it's coming
from, I really dislike the ~user naming scheme, including the usage of /
in email addresses. In its usage area it's weird, unnecessary and also
acting as an unfortunate barrier against the acceptance of Sourcehut.
Small things in UX design could matter. The circle of people interacting
with Sourcehut in one way or in another is much larger than the subset
of registered users preferring these unusual choices.
Ironically these things make CLI usage, otherwise rightly cherished by
most people around here, more difficult. For example, one cannot simply
write
mutt ~petrus/whatever-discuss@lists.sr.ht
It has to be escaped or quoted.
Another UX related example could be the dealing with outputs and
arguments of `hut` with plenty of `#` occurrences.
Just my two cents,
Peter
On Wed, Mar 15, 2023 at 12:35:20PM +0100, Peter Dobsan wrote:
> Small things in UX design could matter. The circle of people interacting> with Sourcehut in one way or in another is much larger than the subset> of registered users preferring these unusual choices.> > Ironically these things make CLI usage, otherwise rightly cherished by> most people around here, more difficult.
Greatly agree. Sourcehut has many unique features whose benefits are obvious
and large, and I'm a fan. It also has some unique features without obvious
benefits, the sort of thing where people end up muttering words like "for
historical reasons...".
The comprehensive Sourcehut API ecosystem means people can and hopefully will
build systems with a different UX. But I feel the default out-of-the-box
commandline UX needs to be as easy as possible to use without escapes. Bear in mind:
* Windows developers are Git users too (look who owns Github)
* Windows developers use Visual Studio, which has 3 commandline environments
(Command Prompt, PowerShell and Integrated Terminal) with various special
characters and command prompt conventions.
* Visual Studio runs on Linux (and I bumped into university students the other
day who think this is normal) where the shells are not the same
Aside from technical escaping issues, on Windows it is normal for "~" to appear in
a directory specification in a command prompt. I'm not a habitual Windows developer,
so you can my scars from command line whiplash in the above comments.
Therefore the fewer funky character schemes in use the more friendly and
portable Sourcehut will be.
--
Dan Shearer
dan@shearer.org
15 Mar 2023 12:35:35 Peter Dobsan <petrus@dismail.de>:
> On Wed, Mar 15, 2023 at 11:26:50AM +0100, Moritz Poldrack wrote:>>> What about using "~~" double prefix?>>>> Not a big fan, to be honest. It looks weird and I am not too sure how >> this>> would make routing easier. Personally, I'd prefer to not have a prefix >> to>> mirror the UNIXy style currently prevalent across sourcehut (~user, ls >> -l>> style file listing, …).>> I could not agree more. Despite of my understanding where it's coming> from, I really dislike the ~user naming scheme, including the usage of > /> in email addresses. In its usage area it's weird, unnecessary and also> acting as an unfortunate barrier against the acceptance of Sourcehut.
Curiously, that's a part I quite like and if your MTA or MUA does not
support the correcr one, there are aliases. So I don't think thats much
of an issue.
> mutt ~petrus/whatever-discuss@lists.sr.ht>> It has to be escaped or quoted.
Only if you have a local user petrus, I tend to go with just my name
instead of my alias.
> Another UX related example could be the dealing with outputs and> arguments of `hut` with plenty of `#` occurrences.
Just out of curiosity: which one? I can't remember every typing a pound
in a hut invocation.
--
Moritz Poldrack
https://moritz.sh
On Wed, Mar 15, 2023 at 01:37:45PM +0100, Moritz Poldrack wrote:
> 15 Mar 2023 12:35:35 Peter Dobsan <petrus@dismail.de>:> > I could not agree more. Despite of my understanding where it's coming> > from, I really dislike the ~user naming scheme, including the usage of /> > in email addresses. In its usage area it's weird, unnecessary and also> > acting as an unfortunate barrier against the acceptance of Sourcehut.> > Curiously, that's a part I quite like and if your MTA or MUA does not> support the correcr one, there are aliases. So I don't think thats much of> an issue.
Sure, I also know many workarounds myself. The point is why waste
resources (mine or my potential users') for these workarounds.
> > mutt ~petrus/whatever-discuss@lists.sr.ht> > > > It has to be escaped or quoted.> > Only if you have a local user petrus, I tend to go with just my name instead> of my alias.
Not in my shell ;-)
% mutt ~sircmpwn/sr.ht-discuss@lists.sr.ht
zsh: no such user or named directory: sircmpwn
> > Another UX related example could be the dealing with outputs and> > arguments of `hut` with plenty of `#` occurrences.> > Just out of curiosity: which one? I can't remember every typing a pound in a> hut invocation.
I was talking about (the discrepancy between) "outputs and arguments".
Like, printing numerical ID-s as #123456 while accepting them like 12345
so making copy/paste them from one command to other more error prone.
% hut git artifact list -r mailctl
Tag 0.8.3:
#3604 mailctl-0.8.3.tgz.sha256
#3603 mailctl-0.8.3.tgz
...
% hut git artifact delete 3604 -r mailctl
On Wed Mar 15, 2023 at 4:35 PM CET, Peter Dobsan wrote:
> Sure, I also know many workarounds myself. The point is why waste> resources (mine or my potential users') for these workarounds.
In my experience only few users actually need them… but mileage may
vary.
> Not in my shell ;-)>> % mutt ~sircmpwn/sr.ht-discuss@lists.sr.ht> zsh: no such user or named directory: sircmpwn
$ echo $SHELL && aerc ~sircmpwn/sr.ht-discuss@lists.sr.ht
/bin/zsh
# opens mail for writing
maybe a misconfiguration?
re: hut gotcha… never noticed them because grabbing the mouse would to
copy/paste would probably take longer than just entering the numbers ^^
--
Moritz Poldrack
https://moritz.sh
> > > Not in my shell ;-)> > % mutt ~sircmpwn/sr.ht-discuss@lists.sr.ht> zsh: no such user or named directory: sircmpwn> > >
This is zsh's extended globbing. You can disable it by removing
`setopt extended_glob` from ~/.zshrc (or potentially a different zsh
setup file). You can also alias commands to ignore globbing, in this
case, add the following line to your .zshrc:
alias mutt="noglob mutt"
--
/*
* Ren Kararou
* PGP: B0BA4EEC0714F8E6
* Site: https://lesbianunix.dev
*/
On 23/03/15 01:37PM, Moritz Poldrack wrote:
> > I could not agree more. Despite of my understanding where it's coming> > from, I really dislike the ~user naming scheme, including the usage of /> > in email addresses. In its usage area it's weird, unnecessary and also> > acting as an unfortunate barrier against the acceptance of Sourcehut.> > Curiously, that's a part I quite like and if your MTA or MUA does not> support the correcr one, there are aliases. So I don't think thats much of> an issue.
Historically, ISPs (at least over here) and universities used a single tilde in
the URLs of user homepages during the early days of Internet. Example:
http://www.some-isp.com/~jsmith
and there wouldn't be any tildes in user's email addresses:
jsmith@some-isp.com
However, the convention is already established on Sourcehut and IMHO it is too
late to change it. Imagine how many changes would be required to the existing
repositories and user's workflows, just because someone doesn't like the
existing naming scheme for emails.
On 23/03/15 12:35PM, Peter Dobsan wrote:
> mutt ~petrus/whatever-discuss@lists.sr.ht> > It has to be escaped or quoted.
What's wrong with quoting? That is a normal part of using the shell. If one is
using this address often enough, the command can even be made into an alias.
Besides, I can imagine that most people who use Sourcehut are using an email
client like Neomutt or aerc, or a GUI mail client like Thunderbird, where this
is a non-issue when email is composed from within the already opened email
client.
> A proposal: we should implement organizations, which are an entity> representing a group of users which can collectively own resources like> git repositories.
I'm curious if this discussion led to some document establishing the way
forward to have organizations in Sourcehut. A roadmap would also be
great.
Drew, any update/deliverable out of this discussion?
Thanks