m0xEE @m0xee@librem.one

Remember when Google were introducing their Privacy Sandbox, one of the claims was that it would help them phase out tracking via third-party cookies? Under this premise they've made others (Yes, Mozilla, I'm looking at you!) adopt the same approach…
Guess what? They won't be: https://tech.slashdot.org/story/24/07/22/2055228/google-wont-be-deprecating-third-party-cookies-in-chrome-after-all
Most probably to avoid lawsuits in EU — as new tracking technology is solely controled by them.
So you get the new "privacy preserving" tracking AND the old one! 😂
This company is pure evil!

I saw a lot of articles about “mandating open source in Switzerland.” This isn’t true. The actual requirement is that the source code must be available (with some exceptions) for software developed within the scope of administration. It's more akin to code escrow than true open source licensing.

Only the paragraph 2 opens the door to FOSS licensing but it also the open the door to non-free license. A list of FOSS licenses should have been mentioned clearly.

#opensource

https://www.fedlex.admin.ch/eli/cc/2023/682/fr

They're starting to venture out from under the couch to play. #FosterKittens

#Caturday #CatsOfMastodon #MastodonCats #猫 #CatWuschel #Katze #catstodon #AdoptDontShop #ねこ #RescueCat #AcademicsWithCats #Fedicats #Gatos #MastoCats #CatContent

RADICLE

Some months ago I learned about Radicle, a truly distributed git forge based on a custom gossip protocol similar to SSB. This allows collaborative code development without the use of any centralised nodes altogether, much less ugly monsters like Github.
See https://radicle.xyz for more details about the implementation.

My experience with it

TL;DR it's almost good, but not quite there yet.

Longer version.

The Good:
Initial setup is easy. Generate keys, run a node, seed your repos, clone others. Despite being fully distributed, Radicle still has a notion of repo ownership, implemented via cryptography. Every repo has one or more delegates, whose versions are considered master copies in case of conflicts.

Unlike other git forges, everything about the repo is the part of the repo. Ownership information, access permissions, PRs, issues, everything is implemented via git objects. You won't ever need to open a browser to submit a PR. Furthermore, you can do all of this while being completely offline. Your work will automagically synchronise once you get internet connection.

For better availability, Radicle has the concept of Seed Nodes. These are (almost) always online nodes with public IPs that donate their disk space and bandwidth for spread others' repos.

The bad:
Bugs. Bunch of them. This is what you get for using software with versions like 1.0.0-rc14. Sometimes my two nodes fail to connect, citing some cryptic error as a reason. My seed node froze up a few times, no idea why.

Radicle is implemented in Rust, which sometimes adds to it peculiarity. It's still better than most Rust software, but logs and errors are cryptic. I'm yet to see a typical Rust stacktrace vomit, though I'm completely prepared for it.

The ugly:
Since there is no centralised authority, there are no centralised identities. Every node is represented by a public key. Which means, every one of your computers will have separate identity. While you technically can share keys between them, this isn't advised. This ultimately results in requiring some form of key management system, which I'm yet to explore.

Private repo support - while being there - is somewhat lacking. Someone with delegate access must list all nodes allowed to receive the repo, including your seed node. In my case, private repos require just three nodes for me alone. For a group larger than one person this might just turn into a nightmare. Have you ever managed SSH access with public key authentication? Similar story.

Seed nodes can either seed everything they touch or they can seed a select list of repos. There is no in-between, i.e. follow a select group of nodes and seed their repos only. Or at least, I couldn't find this feature. Which means, whenever you create a new repo and want to share it between devices using your seed node, you must SSH into it and manually add it to the list.

Discoverability is almost non-existent. Someone needs to provide you with a hash for repo to clone before you can work on it. Some seed nodes employ a web interface to list repos and browse code, but it's less than ideal. Same goes for discovery peers.

Google Won't Be Deprecating Third-Party Cookies In Chrome After All https://tech.slashdot.org/story/24/07/22/2055228/google-wont-be-deprecating-third-party-cookies-in-chrome-after-all?utm_source=rss1.0mainlinkanon