Github losing it's place as *the* center for free/open source development is a good thing.
Replacing it with a new singular centralized piece of infrastructure is a horrible idea, and a great way to have the same fucking problems you have now, but sometime later.
Decentralizing has it's own problems and complications, but, especially for free/open projects, being dependent on a centralized service was never a good idea in the first place.
Post
Replies:
21
So - leave github, let it die, dance on it's grave, go elsewhere.
And if elsewhere starts to get too crowded, or their policies seem weird, or the vibes are off, go elsewhere again. and again. Maybe make your own elsewhere, you can even invite people over, if you have the funding for it.
But take the opportunity to decentralize, to fragment, to get away from poisonous centralized infrastructure dependencies.
A Centralized archive - something like archive.org - is more useful;
Free software has an advantage there, as the licensing explicitly allows archiving.
I'd be fine with a centralized archive of mirrors for projects.
But, mirrors & archives are a distinct issue, from the infrastructure for creating and working on a project.
@miss_rodent archive dot org performs censorship and rejects any form of external accountability
@hipsterelectron Edited to remove the link; was not aware of them censoring things? I know they were legally required/compelled to remove a lot of stuff, but, hadn't heard anything about it beyond that.
@miss_rodent https://circumstances.run/@hipsterelectron/112518180608448528 they lie to journalists about it too
@hipsterelectron Ah fair. Either way, my initial point that centralized archives can be useful still works. Though this highlights why decentralized & redundant archiving is better and also important to have (even if it's alongside a centralized archive.)
@miss_rodent i really really like the approach @OpenArchive does for their DACs https://www.open-archive.org/programs
@miss_rodent @OpenArchive i think we eventually have to flip the archiving situation from "central archive that does lawsuits against publishers and defends against nothing" to "independent archives which prepare from the start to survive hostile takeover"
@hipsterelectron @OpenArchive Yeah, agreed. Centralized archives, even if well-managed, are vulnerable. Redundancy, spread, & decentralization - especially across jurisdictions, social-political-legal contexts, etc. is important, and a lot more robust. (and likely less prone to bias)
@miss_rodent @OpenArchive the fact that openarchive understands that its content is potentially illegal according to a fascist state means it's considered more of these eventualities. i think this is something other archives can learn from. a lot more becomes "illegal" under fascism
@hipsterelectron Yeah, it's dangerous to assume any content may be legal/allowed in perpetuity. Prior to the nazis taking over germany, research into queer & trans people & medical transition was safely legal; that changed very quickly once the nazis took over.
What is legal/protected speech today may become a crime arbitrarily at any point, under new leadership...
@miss_rodent @hipsterelectron In light of all this, archives really should be using content-addressed storage. Makes it easy to mirror and far less productive to try to do takedowns against.
@dalias @miss_rodent there are zero standard protocols in this space which is why IPFS keeps trying to make itself happen. personally i would do some sort of CAS with asymmetric crypto involved somewhere to address the separate problem of surveilling who's uploading and downloading files but i haven't at all figured that part out yet. agree that CAS solves several problems at once and we need not be limited to bittorrent
@hipsterelectron @dalias @miss_rodent Along these lines, would it be possible validate the source of an archive (e.g. that a archive of a webpage hasn't been tampered with)?
I've wondered if it would be possible to record a tls session to use for this, but I haven't done much research / wasn't able to make much sense of it when I did. Would everything interesting be encrypted with the public key of the client, so it could be easily tampered with anyway?
@aren @hipsterelectron @miss_rodent Nope. At least AIUI, TLS intentionally does not provide non-repudiation. I'm pretty sure you can always forge a session that's indistinguishable from a real one.
@aren @hipsterelectron @miss_rodent IIRC this is just a consequence of the private keys only being used for Diffie-Hellman, not for signing anything that's part of the session. Someone please correct me if I'm completely off on this, but it sounds right.
@dalias @aren @miss_rodent i have an even weaker belief that that is correct and how it works. there are a lot of cool things to do with identity here. i would probably start by decoupling identity from TLS which of course doesn't solve the issue unless the web were accessed through a separate format that made such an identity accessible. i think it would be a useful feature for a website to have to enable cryptographic non-repudiation
@dalias @aren @miss_rodent the ability to do so makes it a choice not to do so
@hipsterelectron @aren @miss_rodent It should already be possible. The web server could just add a custom HTTP header containing a signature for its half of the DH exchange.
@hipsterelectron @aren @miss_rodent Actually I'm not sure if that helps anything or if you can still forge the payload anyway, knowing the symmetric key for the session. I'd have to think about it some more.
