<{^_^}>
docker/docker-credential-helpers#124 (by eyJhb, 1 year ago, merged): pass: changed the way for checking if password-store is initalized
<eyJhb>
Docker fading?
<tazjin>
eyJhb: the company isn't doing so well from what I hear
<tazjin>
and in many places their tech is slowly being replaced
<eyJhb>
tazjin: I think that is mostly their buisness model that is failling
<eyJhb>
But, what would you replace docker with?
<tazjin>
containerd, gVisor etc
<tazjin>
GKE nodes already switched to containerd for new pools
<eyJhb>
But doesn't Docker basically just build upon Containerd? And I seem to have some kind of weird idea that gVisor is a runtime for Docker
<tazjin>
it can be, but the point is that in the end there's no tooling from docker itself left
<tazjin>
just implementations of open standards
<eyJhb>
Well... I've heard quite bad things from #golang, seems like when they were in heavy development with Docker, they used to pester them with questions
<eyJhb>
But seems like I might need to figure something else out at some point :p I just like how easy it is to put something together and share
cjpb has joined #nixos-chat
cjpbirkbeck has quit [Ping timeout: 265 seconds]
cjpb2 has joined #nixos-chat
cjpb has quit [Ping timeout: 276 seconds]
pie_ has joined #nixos-chat
pie__ has quit [Ping timeout: 246 seconds]
vesper has joined #nixos-chat
vesper11 has quit [Ping timeout: 265 seconds]
cjp3 has joined #nixos-chat
cjpb2 has quit [Ping timeout: 250 seconds]
__monty__ has joined #nixos-chat
<eyJhb>
Christ.. So I did a SSH Tunnel to get a port from my server to my local machine. Apparantly Transmission does a permanent redirect from / to <somethhing>, which means that anything on port :8080 on 127.0.0.1 now redirects to <something> :p
<sphalerite>
eyJhb: oh yeah I know that feeling… similar with openwrt's LuCI iirc
<sphalerite>
eyJhb: use an nginx proxy with a DNS entry instead? :D
<eyJhb>
Yeah, I should probably just forward it anyways. But it isn't that often that I use Transmission when I am not home anyways.. :p
psyanticy has joined #nixos-chat
<eyJhb>
And seeing as my public facing IP is a VPS, which is always in a range for scanning etc. I just want to have minimal things open to WWW :D
<eyJhb>
I think I only have SSH (non-standard port) and Plex
<eyJhb>
Which I really should convert to Jellyfin instead
<sphalerite>
eyJhb: well you have HTTPS, right? Just hang a basic auth in front of it :)
<eyJhb>
Well, it is already a basic auth in front of it :D
<eyJhb>
That is basically how Transmission does it
<sphalerite>
I prefer to use nginx's basic auth for that sort of thing, if only because it's not vulnerable to bugs in the app it's proxying
<eyJhb>
Yeah, that is also my main concern. Then I have double auth!! :D
<sphalerite>
well, can't you disable transmission's basic auth?
<eyJhb>
Yeah, but then I have the problem of not having any auth at home. Unless I put basic auth on my server at home
<eyJhb>
Which I could, but ... Should probably be at my VPN which actually handles the traffic from WWW
cjp3 has quit [Quit: Quitting now.]
<manveru>
anyone here using krops and know how i'd reference config from machines among each other? similar to the `nodes` in nixops?
__Sander__ has joined #nixos-chat
<infinisil>
manveru: Last time I looked at it I thought that wasn't possible
<manveru>
i get that feeling as well
<infinisil>
What I've been wanting to do for my own config is to put all the settings that need to be shared between machines into their own files
<manveru>
yeah, i think i'll try that
<manveru>
almost migrated all my machines to krops now :)
<manveru>
that plus wireguard is a neat combo
<manveru>
i really wish nixops was faster... doing a 50 machines deploy and it already takes 2 hours :P
<infinisil>
manveru: O(n^2) eval time for interdependent configs doesn't go well for big n yeah..
<manveru>
almost maxes out memory of the deployer machine too
<manveru>
there must be a better way
<infinisil>
I actually have a tree of nixpkgs where it's possible to define a nixops-like config for many machines, each of which interdependent, but only with O(n) eval tiem
<infinisil>
But there are some problems with it I haven't managed to solve yet
<__monty__>
How are you managing that?
<__monty__>
Isn't a topological order the most efficient you can get?
<infinisil>
__monty__: It's really just putting the NixOS config into a submodule, then accessing other machines configs is just `config.<machine>.nixosConfig.*`
<infinisil>
Then you have a single nix instantiation for the combined result of all machines
<infinisil>
The main problem is that submodules don't really work with NixOS configs
<infinisil>
I believe it should be solvable, but I didn't quite manage yet
<infinisil>
That might be doable for the hackday hmmm
<manveru>
i was wondering if you could cut down on the issue by isolating the parts that have to be shared beforehand (maybe even manually)
<manveru>
i think some combination of terranix+krops could achieve that
drakonis has joined #nixos-chat
<fpletz>
manveru: pong, if I read correctly it's concering c3; I probably won't be there but I can get all of you tickets :)
* joepie91
will be going to congress
<manveru>
fpletz: awesome! :)
<joepie91>
hmmm. maybe I should try to get my newly-acquired flipdot to work before congress
<elvishjerricco>
manveru: I prefer a message saying "All units healthy" over "0 loaded units"
<elvishjerricco>
Like how `zpool status -x` outputs `all pools are healthy` when everything is fine
<manveru>
alright :)
<manveru>
it still annoys me how i have to restart two units everytime i login :|
<manveru>
there's a race condition with my systray...
<gchristensen>
Restart="always" ? :)
<Taneb>
manveru: can you add an ordering constraint to fix this?
<manveru>
there's a constraint already to load after polybar, but polybar doesn't immediately have a systray
<manveru>
gchristensen: i think that's missing, yeah
<joepie91>
manveru: hacky solution: put a timer in the dependency chain?
<Taneb>
...how is the systray detectable? Could you have a .file unit to fix this issue?
__Sander__ has quit [Quit: Konversation terminated!]
qyliss has quit [Quit: bye]
qyliss has joined #nixos-chat
qyliss has quit [Remote host closed the connection]
qyliss has joined #nixos-chat
<Taneb>
peti looks more like gchristensen's GitHub profile pic than gchristensen does
<gchristensen>
lol
drakonis has quit [Quit: WeeChat 2.6]
<gchristensen>
I used to shave my head :)
<adisbladis>
It's funny how "congress" just implicitly means the CCC congress in hacker circles :D
* etu
has tickets to congress:)
<etu>
:D
<adisbladis>
Almost no matter where you go in the world you can just ask "are you going to congress" in a local hackspace and ppl know what you are talking about
drakonis has joined #nixos-chat
<joepie91>
adisbladis: ha, yeah
drakonis_ has quit [Ping timeout: 240 seconds]
<adisbladis>
Btw, I still have an unclaimed voucher
<ashkitten>
gonna set nix daemon nice levels to max
<gchristensen>
that is an interesting choice
<ashkitten>
on a desktop system i don't want it to interfere with my gaming
<ashkitten>
:p
<gchristensen>
how do you feel about responsive nix-shell's?
<ashkitten>
hrng
<gchristensen>
can you nice down by group?
<ashkitten>
wdym
<gchristensen>
like can you somehow tell the kernel that all processes in the group "nixbld" is very nice?
<gchristensen>
then nix-shell will be responsive, but builds will be not
<ashkitten>
honestly i'm just gonna wing it for now
<gchristensen>
cool
<ashkitten>
test out what this is like
<joepie91>
adisbladis: would recommend to manage the voucher purchases centrally; we've been doing that with revspace with much success last year, and doing it again this year (https://revspace.nl/36C3_Tickets)
<joepie91>
goes much faster
Jackneill has quit [Remote host closed the connection]
<joepie91>
(got 39 tickets last year)
drakonis has joined #nixos-chat
drakonis has quit [Ping timeout: 245 seconds]
psyanticy has quit [Quit: Connection closed for inactivity]
drakonis has joined #nixos-chat
buckley310 has quit [Read error: Connection reset by peer]
buckley310 has joined #nixos-chat
buckley310 has quit [Read error: Connection reset by peer]
buckley3101 has joined #nixos-chat
buckley3101 is now known as buckley310
buckley310 has quit [Client Quit]
buckley310 has joined #nixos-chat
<drakonis>
hmm, so sourcehut might have different workflows in the future
<drakonis>
rather than being just email based
<qyliss>
really??
<qyliss>
isn't email, like, the point?
<sphalerite>
gchristensen: you can do something like `renice -n 19 -g $(pgrep -G nixbld)` to make all current processes belonging to the nixbld group (modulo race conditions) extra nice
<drakonis>
apparently there are other folks that don't like the email only workflow?
<drakonis>
the main focus is still email tho
<sphalerite>
gchristensen: or, well, set the niceness of nix-daemon so that all children of it are nice (or less nice) too
<drakonis>
the others will always be second fiddle
<qyliss>
why don't they use gitlab?
<drakonis>
perhaps because srht has other interesting tools
<sphalerite>
gchristensen: you can probably do that in the systemd unit as well as at runtime.
<qyliss>
what's your source on this, btw?
<drakonis>
and isnt gitlab severely limited unless you pony up money?
<sphalerite>
gchristensen: oh I see what you mean now. I don't think there's a way to do that specifically, you'd have to implement it in nix-daemon probably
<gchristensen>
and it allowed fine-grained control for push permissions
<drakonis>
hm, i see.
<drakonis>
the appeal of not owning your infra seems annoying
<gchristensen>
hm?
<drakonis>
unappealing that is
<tilpner>
On the other hand, our issues don't break just because graham goes on vacation c.c
<drakonis>
i meant that this seems annoying that you need an separate user just for that
<drakonis>
that looks like sysadmins.txt :V
<tilpner>
(If you were comparing to self-hosting git)
<drakonis>
i'm comparing to self-hosting git, yes.
<drakonis>
any other decent git frontend that isnt entirely an secret to all
<tilpner>
It seems unrealistic to switch at this point
<drakonis>
github seems to be getting incontrollably more social media-y
<tilpner>
Lots of tooling is written around GH, all would be lost when switching to GL
<__monty__>
Tbh, it's the only social media I enjoy.
<gchristensen>
we certainly get a lot of value out of github
<drakonis>
gitlab isnt the only option but it is the only one that directly maps to github
* joepie91
would certainly not consider gitlab an improvement over github
<joepie91>
(UX-wise)
<gchristensen>
I can never figure out how to actually view source code on gl
<gchristensen>
and frankly, I'm not sure GH -> GL is much better in many aspects at all
<tilpner>
As much as I want NixOS to use FOSS tools, the cost would be too high
<__monty__>
Only in the "self-hosting's an option" way afaict.
<drakonis>
GL's main advantage is public source
<drakonis>
gitea and gogs are
<drakonis>
kind of ok at best?
<tilpner>
And sourcehut and cgit are too different
<__monty__>
Oh, and the team does seem to try to respond to issues from significant projects quickly. But either they're too small or badly managed?
<drakonis>
its all light
<drakonis>
srht is a work in progress right now, its not going to replace github until it can properly support a web workflow for the average developer
<drakonis>
the community cost is too high right now
<drakonis>
cgit is absolutely not built for the things nixos needs
<gchristensen>
heh
<drakonis>
it ranks below gogs and gitea which are basically cgit with a new stylesheet
<andi->
That being said we should probably try to keep a record of our data outside of github in case we ever have to migrate.
<gchristensen>
+1
<drakonis>
agree
<gchristensen>
if anyone wants to take that on, I can hook you up with the full event stream
<tilpner>
I have an up-to-date database of issues/PRs, but without the comments
<andi->
I was thinking of at least logging that event stream to somewhere. In the future we could reply that if needed. Not sure if there is a better way to grab everything (e.g. comments on a commit)
<joepie91>
drakonis: ehhh. gitea/gogs are quite a bit more than cgit
<drakonis>
the one thing srht shows promise is that once it goes subscription based, the free option is to self host, but it has all the bling the paid version would have
<joepie91>
it has actual project management :P
<joepie91>
(not particularly good project management, owing to where it inherits its model from, but still)
<drakonis>
gitlab has a lot of bling that needs to be built on top of other options
<andi->
I think something like srht is already a good move. Given how young it is I still have high hopes.
<drakonis>
rather, things that the other options, ie: not github or gitlab, have to set infra for
<joepie91>
well, "needs"... the question is how much bling is actually needed
<drakonis>
yes
<joepie91>
how much of that *
<joepie91>
andi-: I find the direction to be hopeless
<joepie91>
andi-: the problem is that sourcehut is built around nostalgo-simplicity; ie. the misleading kind of "simplicity" that's not actually simple in a UX sense, but rather "barebones, reminiscent of how old computers used to work", and that approach pretty much never leads to tools that are *actually* pleasant to use for anyone but those who are most heavily invested into it
<joepie91>
UX-wise, sourcehut is almost a cgit clone
<joepie91>
but with more features
<drakonis>
there's CI, except it doesnt cost you money
<joepie91>
and it's very clearly trying to appeal to a sense of nostalgia, of "things used to be better", and unless that direction changes I just don't see it having a future outside of the circles of developers who a) grew up in the 80s/90s, and b) are interested in that sort thing
<drakonis>
actually, did you not see that there's a web workflow now
<drakonis>
at least one being developed right now
<joepie91>
and if you run a heavily community-oriented project, like NixOS, that is a problem :)
<joepie91>
drakonis: that doesn't change my fundamental point
<andi->
I for one am a huge fan of allowing people to contribute via mail. That doesn't mean that everyone has to use it and that is why I think srht current is promising. You can use it but you can also open a PR otherwise IIRC.
<joepie91>
it matters what philosophy underpins the design of a thing; the actual bits and pieces being built are just implementation details
<joepie91>
the implementation details don't tell you what it's going to look like in 5 years; the underlying philosophy does
<__monty__>
Nostalgia doesn't appeal to me as a reason something has to be bad. I don't see any github UX that wouldn't be possible to implement backed by email.
<drakonis>
there are advantages to be had from the model for some
<joepie91>
andi-: there's no reason why "allowing contributing via e-mail" would require this sort of nostalgo-simplicity
<joepie91>
it's immaterial to my argument
<drakonis>
github is extremely poor at contributing via email
<drakonis>
or any other model outside of the one imposed
<andi->
it just doesn't support it
<andi->
it is very hostile vs not trying to fully buy into their offerings
<joepie91>
I am aware. that is a github problem, not something that makes sourcehut promising.
<drakonis>
the thing that does make it promising is the featureset being semi on par with the competition and not costing a pretty penny
<__monty__>
But the github problem seems mostly shared by everything but srht.
<andi->
drakonis: I don't see cost as an issue. I see the license and the ability to customize it as a feature.
<joepie91>
drakonis: that is unrelated to UX.
<__monty__>
But the email backend is also orthogonal to UX.
<__monty__>
Yet you argue it's a fundamental problem.
<drakonis>
the UX can be swapped out at any time
<drakonis>
as long as the backend is solid
<joepie91>
drakonis: doesn't work that way.
<joepie91>
at least, not for most things.
<gchristensen>
I think the fundamental thing joepie91 is referring to is the author of srht very very much likes the nostalgic style of things
<joepie91>
that only applies if "the backend" is designed entirely neutrally to the frontend, which is true for almost nothing
<drakonis>
oh yes he does, quite a lot.
<drakonis>
the backend is email
<joepie91>
drakonis: yeah, so that isn't neutral to the frontend at all.
<joepie91>
using e-mail as a backend immediately subscribes you to a laundry list of limitations and considerations
<joepie91>
nearly any 'modern' UI you try to implement based on that will feel weird, fail in strange ways that are difficult to understand for new users, and have to deal with a lot of complexity
<joepie91>
think spamfilters, open relay issues, e-mail encoding mismatches
<joepie91>
too high overhead for anything (semi-)realtime
<joepie91>
and so on
<__monty__>
joepie91: Those don't apply if the github model is used though, where all of those emails are in-house. And don't actually have to touch smtp or anything ever.
<joepie91>
at which point what's the point of e-mail? you're just introducing a lot of unnecessary protocol complexity
<joepie91>
there's no reason why e-mail couldn't just be one of many interfaces for a much simpler backend
<__monty__>
I wonder if their nostalgia is strong enough to overcome economic incentives in the face of a team too. (Yes, I'm assuming we're not talking about a superhuman who can run a github-size product by themselves.)
<joepie91>
making e-mail the backend seems like a decision that is very difficult to technically justify.
<gchristensen>
well they added web-based patch submission, so I think that shows he's listening to customers instead of blindly following nostalgia
<drakonis>
that's the thing i mentioned earlier
<joepie91>
gchristensen: sure, but I think that somewhere in the next few years he's going to run into serious issues reconciling customer requests with his chosen technical architecture
<samueldr>
isn't git by git people built on the e-mail workflow?
<drakonis>
samueldr, yes
<joepie91>
samueldr: not particularly
<gchristensen>
hah
<joepie91>
it is entirely possible to use Git to collaborate with people without ever involving e-mail anywhere, including internally
<drakonis>
before we continue with this, where does it actually say it is an email backend for everything?
<__monty__>
The linux kernel's a definite example of the email workflow being workable though. Even without the support of a product like srht.
<joepie91>
Git does the "one of many interfaces" thing
<joepie91>
drakonis: (you did, a few minutes ago)
<samueldr>
I understand most other ways to collaborate with git as a side-effect of branching, merging and remotes
<drakonis>
aight
<drakonis>
let me find a source
<drakonis>
because i am doing a booboo if i'm wrong
<samueldr>
while there is an interface within git made for the e-mail workflow
<drakonis>
that old adage "source your quotes" should apply to me
<joepie91>
samueldr: `git push` and `git pull` were originally designed as a general-purpose object exchange mechanism, that could function P2P over arbitrary protocols
<joepie91>
(or well, more or less arbitrary)
<gchristensen>
and still can
<joepie91>
e-mail is certainly a supported workflow in Git, but it is not the supported workflow
<__monty__>
Why has no one applied DHTs to git yet?
<gchristensen>
they have
<__monty__>
They have?
<samueldr>
right, but push/pull send git objects like commits, tags, branches. what I'm saying here is that *that* is not a collaboration workflow. the only one designed within git (to my knowledge) is the mail workflow... and even then, it's only tangentially designed into, considering it lets the user manage the e-mails through other means
<samueldr>
I'm not saying that building another contribution workflow on top of it is an issue though :)
<joepie91>
samueldr: huh? the push/pull stuff definitely *is* a collaboration workflow. what makes you think it isn't?
<samueldr>
I still need to tell you, through another means, hey joepie91, look at branch XYZ and merge if you want (a pull request)
<samueldr>
the request itself isn't managed within the git software
<__monty__>
Yeah, all you need is ssh access or http, no?
<joepie91>
yes, that is part of that workflow, the communication being out-of-band
<joepie91>
specifically, out-of-band in such a way that it doesn't "mechanically" integrate with Git
<joepie91>
eg. literally sitting next to someone at work
<joepie91>
or coordinating via IM or whatever
<samueldr>
point is the only interface built into git for collaboration (and even then, not that tightly integrated) is the e-mail workflow
<joepie91>
yes....? because that is what was available and integratable at the time
<samueldr>
kinda forgot where I was going with that point though...
<__monty__>
gchristensen, you tease.
<__monty__>
joepie91: That doesn't sound right. I think the motivation was that's what the kernel team wanted?
<gchristensen>
"git config --global sendemail.smtpPass 'your password'" is a sketchy suggestion
<__monty__>
Because the password ends up in your shell's history?
<drakonis>
looks like that's the app password
<drakonis>
still sketchy tho
<gchristensen>
it ends up in a file which by default is likely readable by other users (~/.gitconfig)
<gchristensen>
and "app passwords" are a thing for gmail and some other mail hosts, but not universally a thing
<drakonis>
btw github does that i'm not crazy for, is forking
<drakonis>
there's people that have hundreds of repository forks that they never do anything
<drakonis>
its clutter
<drakonis>
most forks are for one off patches and others are for showo
<drakonis>
s/showo/show
waleee-cl has quit [Quit: Connection closed for inactivity]
<qyliss>
gchristensen: at least on NixOS, that file shouldn't be read-only
<qyliss>
*readable by other users
<qyliss>
because your home directory is, IIRC, 0700
<qyliss>
I agree that a workflow can be repopularized due to nostalgia but still be better
<qyliss>
I wasn't alive for the vast majority of the 80s and 90s but still prefer the workflow
<qyliss>
There are several things about it that are just so much better
<qyliss>
Explaining GitHub to somebody is: "find the code you want to change, make a github account, fork it, switch to terminal, clone it (upstream, not your fork), make your changes, make a branch, commit your changes, add your fork as a remote, push to GitHub, switch to browser, open a pull request"
<drakonis>
that is a lot of steps
<drakonis>
i would honestly prefer to just clone the repository, change, diff, send patches
<qyliss>
Exactly
<drakonis>
seems relatively pain free
<gchristensen>
interacting with my mailbox is a very painful experience
<qyliss>
The email workflow is "find the code, clone it, make changes, commit them, configure your email account if it's not set up on your system, git send-email"
<drakonis>
the web workflow can still be optimized
<qyliss>
gchristensen: there's nothing stopping you having a seperate mailbox
<gchristensen>
that is part of the problem!
<drakonis>
make a better email client!
<qyliss>
I'd really like to write a gui mail client just for applying patches
<gchristensen>
`rm` is a perfectly fine mail client, thank you
<drakonis>
sircmpwn got you beat there
<__monty__>
<3 gchristensen
<{^_^}>
gchristensen's karma got increased to 166
<qyliss>
drakonis: did he?
<drakonis>
its TUI tho
<qyliss>
Right
<qyliss>
Not acceptable to my target demographic
<qyliss>
And it's not just for that, it's a generic mail cient
<qyliss>
Which I'm sure is great
<qyliss>
But it's no better at applying patches than mutt is
<qyliss>
I want a "connect to email provider, list patches, point and click to apply" thing
<qyliss>
I want this not for myself, but for others, because I think it's the missing piece of the puzzle
<drakonis>
oh, yeah that'd be pretty sick
<gchristensen>
pop, then?
<qyliss>
Hmm?
<drakonis>
smtp but it hooks to your repository?
<gchristensen>
"connect to email provider" -> POP?
<__monty__>
Please, let's not resurrect POP.
<drakonis>
POP is an abomination
<drakonis>
for some godawful reason, POP3 on thunderbird downloads attachments
<andi->
If mail isn't an option what do you imagine to support for one-off contributions of people that can't or wont have an account on your $service? I do not have a solution. I am interested to hear your opinions. The main problem is going to be spam?!
<gchristensen>
I think mail must be an option
<andi->
It is the only federated system that actually got traction.
<andi->
I wouldn't mind a git push new-pr-target <my-branch>
<drakonis>
git doesnt actually have github's PR system built in
<__monty__>
IRC does have traction, at least among developers : )
<gchristensen>
`git send-email` and `git am`
<drakonis>
IRC has to deal with slack and discord
<drakonis>
its git request-pull apparently
<gchristensen>
IRC isn't federated, really
<drakonis>
IRC used to be federated
<andi->
nah, never was
<drakonis>
until the great providers came in
<__monty__>
Closed federation is still federation.
<andi->
it was federated between a closed set of servers
<drakonis>
seems to be apocryphal
<gchristensen>
whatever
<andi->
so github is federated? ;-)
<gchristensen>
github is
<gchristensen>
:D
<drakonis>
something to do with eris?
<gchristensen>
hail eris?
<drakonis>
git is closer to svn
<drakonis>
github
<drakonis>
its centralized repos all the way down
<drakonis>
efnet stands for eris free network
<drakonis>
because of irc's federation
<gchristensen>
that isn't very discordant
<drakonis>
they would swarm in and ruin everything
<__monty__>
Please explain? I don't know of any technical reasons it has to be closed.
<samueldr>
kinda is, kinda isn't
<drakonis>
its kinda complicated
<andi->
you could accept any peer servers but usually that would end up in a bad situation
<gchristensen>
I run my IRC server at irc.gsc.io. how do I send a message to __monty__ on freenode?
<drakonis>
irc as is today is not really federated at all, its a bunch of isolated networks
<samueldr>
made for a simplet internet, where there were no bad guys
<samueldr>
simpler*
<__monty__>
*isolated federated networks.
<gchristensen>
uhh
<samueldr>
the room we are in, is federated among linked servers
<samueldr>
servers have to opt-in a link
<drakonis>
netsplits come to mind
<gchristensen>
yes, in the same way that github is federated
<samueldr>
in fact, we're likely on many different servers now
<gchristensen>
and it isn't federated over the IRC protocol
<drakonis>
i'm here from tolkien.freenode.net
<__monty__>
The difference is that irc *could* be open federated. While I wouldn't expect github to work well that way. I assume they rely on server in the same datacenter much of the time.
<samueldr>
right, link protocols differ between server implementation
<samueldr>
though there is _a_ link protocol for IRC that is spec'd
<drakonis>
gchristensen, you're in here through adams.freenode.net
<gchristensen>
I know
<drakonis>
it can theoretically become federated again
<samueldr>
it technically can be federated, but is all opt-in and in practice only used as a load balance
<drakonis>
rules enforcement be damned though
<gchristensen>
whatever okay
<samueldr>
it has many deficiencies to make it a _good_ federated protocol
<andi->
How does that help us with contributions? :-)
<gchristensen>
I think we are still disproving to you that other federated protocols exist and have wide traction
<samueldr>
no idea, saw the discussion was about IRC when I got back in :)
<gchristensen>
using the key example of IRC, being a widely used protocol
<__monty__>
I'm not-a-fan of coopting federation to mean "open federation." There's nothing wrong with precise terminology no matter how many fancy matrix and mastodon projects sprout up.
<drakonis>
by the way, if the github model is shed, it becomes easier to do things
<drakonis>
because you don't have to store thousands of copies of the same repository
<samueldr>
could it also be that there are multiple ways to see federation? the technical "independent servers speaking to eachothers", and then "here my identity is from that server, shared across a network"
<drakonis>
there's 4.1k github forks
<gchristensen>
(which github stores roughly once, of course)
<samueldr>
when I'm thinking "federated", I see "I can be samueldr@samueldr.com" on it, and control that identify
<samueldr>
identity*
<andi->
same here
<drakonis>
i wonder how they implement that
<samueldr>
which IRC, in the protocol, has no identity federation
<drakonis>
because there's a significant amount of copies that date to years ago
<samueldr>
at least, not in that sense
<andi->
there was some work on having "open" federation in ircv3
<andi->
not sure what happened to the idea
<gchristensen>
drakonis: in the backend, everybody shares the same bare repository in storage
<drakonis>
ircv3 died again
<drakonis>
hm
<drakonis>
the frontend exposes different points in the repository for the users?
<drakonis>
and then patches on top of that?
<samueldr>
what I entirely dislike from all current hosted forge software, is that my identity is not federated; I create a project on _their_ turf, on which they lend me my name
<joepie91>
but yeah, I'm quite disappointed at the way this has been approached
<__monty__>
joepie91: Federation is connection among networks using a standard protocol, so 1-to-N, rather than M-to-N. A single server can be a degenerate instance of a network though.
<joepie91>
__monty__: what do you mean with "1-to-N, rather than M-to-N"? that seems unrelated to "connection among networks using a standard protocol" -- also, "networks" is underspecified, what constitutes a network?
<drakonis>
some of the options they considered before getting rid of
<drakonis>
gitter lol, wtf.
<joepie91>
drakonis: btw, I had a conversation with one of the people involved in this on the Mozilla side, that explained a lot of how things have been handled
<__monty__>
joepie91: That's just to clarify. You could have connected networks that each "standardize" on an interconnect but use a different interconnect among any two. And network can be whatever pretty much from a single entity to a WWW.
<joepie91>
namely: the entire thing isn't being treated as a community venue, it's being treated as a public-facing corporate venue (think like the Texas Instruments forum, or the Discourse instances that some startups have)
<joepie91>
hence why the community was cut out of the loop
<joepie91>
__monty__: by that definition virtually everything is federated, including P2P things, and the term loses meaning
<joepie91>
it's a broader definition than even "decentralized"
<joepie91>
like, two networks operated by two subsidiaries of the same company would, by that definition, be federated
<__monty__>
Not really. P2P is a special case but there's far more things that are federated than P2P. Things can be decentralized without being federated, cf. 1-to-N.
<__monty__>
Only if the networks are connected with a protocol suitable for connection to other networks.
<joepie91>
both the P2P and different-subsidiary scenario appear to fit your definition.
<joepie91>
if you think they shouldn't be included, then your definition is imprecise :)
<__monty__>
P2P fits. It's like federation in the limit.
<__monty__>
You didn't give enough details about these subsidiary networks to decide whether or not I agree it's a case of federation.
<joepie91>
yet people would not generally understand P2P to be "federation" (not even before Matrix/Mastodon/etc.), because it's missing the crucial property of delegation of trust to a chosen party
<joepie91>
__monty__: what information are you missing?
<__monty__>
As I said, whether the networks are connected with a protocol suitable to federation.
<__monty__>
I agree that precise terminology is important. So you'd use P2P when you can.
<__monty__>
Though delegation of trust is an acceptable addition to the definition as far as I'm concerned.
drakonis has quit [Ping timeout: 268 seconds]
<gchristensen>
to me, federation is delegation of ownership
<joepie91>
__monty__: HTTP is suitable to federation
<joepie91>
so if the subsidiaries used HTTP, it would be federation?
<joepie91>
even if there is no trust delegation and it's a closed network?
<joepie91>
(under your original definition)
drakonis has joined #nixos-chat
<gchristensen>
tricky question, joepie91 :)
<joepie91>
gchristensen: hey, I don't get paid for the easy questions :P
<__monty__>
I wouldn't say it can't be federation. Still not enough details.
<__monty__>
Like I said, P2P can be a special case of federation. So trust delegation isn't a requirement imo.
<__monty__>
I've also said I don't mind that being a requirement.
<gchristensen>
SMTP doesn't delegate trust
<__monty__>
I do take issue with the *open* part being a requirement.
<__monty__>
Wait, didn't you say email was a federated system *and* that you consider trust delegation a requirement for federation?