なんか良いゲームあったら教えてね
It completely upends the social media power structure when you try to follow back someone who follows you, but it's a "request to follow" situation
That is how the fediverse keeps a bunch of jerkoffs from going mad with power
incredible take from one of the GNU maintainers, seriously
@ariadne
WTAF?
I've been carrying around an idea for a federated code forge for a while. Two things sharpened it recently: Tangled's post on the federated code forge, which builds a forge on the AT Protocol, and a Jujutsu workshop (Korean) by Seongmin Lee (@boltless.me), who works at Tangled, held at @turingappledev.
My version would build on ForgeFed, the #ActivityPub protocol for code forges (spec), so that repositories, issues and merge requests federate the way posts already do. The idea is early enough that I haven't even come up with a codename. What I want from it, roughly:
- Git and Jujutsu (so-called
jj) as equal clients. Not Git hosting with Jujutsu support bolted on, but a forge that understands both, so what Jujutsu is actually good at, stacked changes, becomes a first-class unit of review instead of a pile of separate pull requests. - No owner layer. Since the point is federation, one instance represents one person or one organization, permissions are managed per server, and a repository lives at
forge.example/myrepoinstead offorge.example/owner/myrepo. - A migration path off GitHub that keeps the history. Importing the code is easy; importing the issues, pull requests and discussions with their original authors attached is the part that matters. I'd keep a placeholder for each GitHub account and let whoever owns that account prove it, after which the instance swaps in their fediverse actor, so attribution carries over. How to express that claim in ActivityPub is the part I haven't figured out. It may need a new FEP.
Where this stands: I haven't read the whole #ForgeFed spec, Fedify doesn't ship the vocabulary yet (fedify-dev/fedify#751), and I have too much else going on to start soon. If you've run a forge or implemented ForgeFed, I'd like to hear whether any of this makes sense.
なんか良いゲームあったら教えてね
incredible take from one of the GNU maintainers, seriously
Just remembered Mitra-tan from earlier and my GPU is still tied up with other stuff! Really tempting to get one of those little 128GB boxes these days
Just remembered Mitra-tan from earlier and my GPU is still tied up with other stuff! Really tempting to get one of those little 128GB boxes these days
I love the #Fediverse but I'm dreaming of something truly decentralized using public keys for identifiers and something similar to the #NASA delay-tolerant network for distribution. No email addresses ever used to identify someone - that's an old system we need to move past.
The beauty of this would be to have key-signing in person so you could show on your feed "I've met this person, they're real, I know them and here's their pubkey to follow -- they aren't AI" and through the six-degrees-of-separation thing we can all follow REAL people and what they engage with. No AI Bots. If there are bots you wanna follow, sure, follow those keys too - but they aren't people and can't show up at key-signing parties and post pictures with us so that's different.
Also, any email service is a public thing that someone might find your leaked password for, etc.
I want my identity backed by a secret key that lives only on my computer -- and part of a wallet of keys that includes ones that I keep offline entirely and only use if the current key does get compromised and yoinked off of said computer.
And IDEALLY I want to have a little USB thingy that has the key and can't be read by my computer - I wanna just be able to send it text and read back the signature for it and never ever have to risk that secret key being stolen thanks to a vibe-coded update to my Linux distro or Python libraries or something sometime in the future.
We have the basic tools to do all that - it's simple off the shelf stuff we could actually do with no real new work needed - just use keypairs (or rather sets of pairs as above, not just a single all-or-nothing loss point) and identify ourselves by them. And then meet and do key-signing and know and tell the network that this person is real.
Anyone? Can we start doing that someday soon before AI slop and AI hacks of email services bring this lovely place we have down? #pubkey #p2p #identity #keysigning #fediverse #email #security #aislop #makestuff
And once we have that worked out in software using simple off the shelf stuff on hand and the simplest protocols possible, then can we do usb dongles so we can be really really really sure the private keys stay safe? Hint: There's a product that can be made and sold by sites as an additional stream to help fund public portals to the signed-fediverse.
Dongle should have a physical switch that has to be turned on to flash a set of key-pairs to it and then when turned back appears as a USB device that can be sent text (which could include hashes and checksums for non-text content) and an EOF character and should return a set of signatures using all of the private keys on it (software ignores all but the one we care about).
Maybe no switch, just an SD slot but no USB storage interface or anything presented to the computer, the SD has to be written with the private keys and then inserted but is then safe from being read by anything but the dongle.
Maybe add a touchscreen to require entering a pin/password after inserting the dongle into your computer, but it doesn't really need that.
Okay.. Long rant for the evening finished. Slop Bad, Key-Pairs are a good way of identifying folks, phone numbers and email service providers aren't so much so anymore I'm thinking. And bots can't come to key-signing parties at the local coffee house.
Plus - key-signing parties at the local coffee house sounds nice, actually meeting people in the real world to prove you're human also means... actually... meeting people... in the real world... I kinda remember that, I think?
Perhaps you need not start from scratch. There are a ton of efforts, most of whom go unnoticed and peter out, since it is hard to get uptake and find adoption. Some that pop into my head right now are:
A network based on #IPFS #Hypercore and #BitTorrent exists: #PeerSky
Similar direction, built by cryptography experts, is #Veilid:
https://veilid.com/documentation
A fediverse effort that comes in the direction is what @Steve_Bate just posted about and is developing..
@BobLefridge I'm jealous. I've only seen video of him performing live.
For me his Sweetwaters gig was the best. First half acoustic, 2nd half electric. It was a beautiful evening with a great crowd and he really enjoyed himself.
When he finished, Elvis Costello & the Attractions were up next. It was a helluva night.
Age and alcohol slowed John Martyn down. There was a London gig with a big band but his performance lacked soul. Less passion, more contractual obligation to a record company.
The last gig I caught was in a pub in South London on a weekday. I went on my own and it was sweaty, noisy and gutsy as fuck. The real John Martyn, just older.
I played a live version of him doing "Over the Rainbow" at my Mum's funeral. People cried.
I still love his work.
I've been carrying around an idea for a federated code forge for a while. Two things sharpened it recently: Tangled's post on the federated code forge, which builds a forge on the AT Protocol, and a Jujutsu workshop (Korean) by Seongmin Lee (@boltless.me), who works at Tangled, held at @turingappledev.
My version would build on ForgeFed, the #ActivityPub protocol for code forges (spec), so that repositories, issues and merge requests federate the way posts already do. The idea is early enough that I haven't even come up with a codename. What I want from it, roughly:
- Git and Jujutsu (so-called
jj) as equal clients. Not Git hosting with Jujutsu support bolted on, but a forge that understands both, so what Jujutsu is actually good at, stacked changes, becomes a first-class unit of review instead of a pile of separate pull requests. - No owner layer. Since the point is federation, one instance represents one person or one organization, permissions are managed per server, and a repository lives at
forge.example/myrepoinstead offorge.example/owner/myrepo. - A migration path off GitHub that keeps the history. Importing the code is easy; importing the issues, pull requests and discussions with their original authors attached is the part that matters. I'd keep a placeholder for each GitHub account and let whoever owns that account prove it, after which the instance swaps in their fediverse actor, so attribution carries over. How to express that claim in ActivityPub is the part I haven't figured out. It may need a new FEP.
Where this stands: I haven't read the whole #ForgeFed spec, Fedify doesn't ship the vocabulary yet (fedify-dev/fedify#751), and I have too much else going on to start soon. If you've run a forge or implemented ForgeFed, I'd like to hear whether any of this makes sense.