@steffo the creator has shelved it. According to the last blog post on the topic, he's willing to hand it off to someone else.
It was a *really* ambitious scope
@steffo the creator has shelved it. According to the last blog post on the topic, he's willing to hand it off to someone else.
It was a *really* ambitious scope
@thomasfuchs students have famously never barricaded a public space as a protest tactic before
Reminder not to eat the rich.
The rich are apex predators, and they accumulate high concentrations of environmental toxins.
Instead, you should compost the rich
This might be a bit of a stretch, but do I know anyone who does something like brand identity design work? Or who wants to? I'm thinking about stuff like logos, typography, brand colors, and related. This would be for a personal open source project, so the budget is small but non-zero.
For some reason Golang seems to be the most popular choice? Is it the code generation features? Because otherwise, I can only image that handling AP docs is absolutely miserable in go.
@mattly I'm no fan of Ruby as a language or ecosystem. Even less so of rails. I just think it's notable that Mastodon doesn't seem to have produced any local benefits for working with activitypub, or any of the other specs involved in real world federation. Or if they did, it didn't foster any kind of locally favorable micro climate, as it were
Given how many fedi servers are out there, it's interesting to me that I can only find one written in Ruby. You'd think that a long running successful project would just naturally produce resources that other projects can use. But that doesn't seem to have happened.
Extremely not comprehensive list of ActivityPub microblogging projects you could contribute to, instead of forking mastodon
https://github.com/superseriousbusiness/gotosocial
https://github.com/misskey-dev/misskey
https://github.com/bonfire-networks/bonfire-app
https://github.com/go-ap/fedbox
https://akkoma.dev/AkkomaGang/akkoma
https://iceshrimp.dev/iceshrimp/Iceshrimp.NET
https://github.com/Letterbook/Letterbook
I don't know who needs to hear this, but I'm getting tired just thinking about the testing path you would need to follow in order to fork mastodon and keep it as an in-place upgrade from baseline.
1. stand up a baseline mastodon instance
2. federate with some peers
3. fill it with realistic data
4. migrate to the fork
5. test the fork
6. test federation
7. repeat across several combinations of mastodon base versions and other fedi servers
8. rapidly, during development
If in-place upgrades aren't the goal, then just build something new. Or contribute to one of the various preexisting projects. Don't adopt mastodon's tech debt for no reason. It's not worth it.
I know I'm eager to have more help, if existing projects suddenly sound better.
@mattly @lennon I'm pretty sure most every multi-user server software supports federated key rotation at this point. I forget who, but someone went on a quest to get it implemented in a bunch of places some time last year
@inthehands they also often just make up gunfire reports that never happened. Not even like false positives. They just lie about things that never happened. Sometimes because cops ask them to. Sometimes just on their own initiative, to sic cops on neighborhoods that were just minding their own business.
@inthehands @Lana same energy
@mattly This is high key cursed.
I'm with you that git is actually supposed to be distributed. But, git is not a package registry, and it's extremely not a task orchestrator. A great many automation boondoggles begin by ignoring one or both of those facts.
@mattly Like, the production server also hosted the (a?) git remote?
Suppose you wanted to host some software, and you're trying to be responsible so you do it gitops style. Imagine it's some fedi software, if you like. BUT! You don't want to do it in kubernetes, because you're just one tired queer, not a whole SRE team. And not using hyperscaler cloud stuff, for the same reasons. Just a VPS or two, running a custom app, with config, a db, a load balancer, that's probably it.
Is there a realistic tooling option to support that, other than Ansible?
btw, I say both terms and conditions specifically, and on purpose. We usually focus on the conditions when we talk about collective labor action. Things like schedules, safety, and sick leave.
When we talk about terms, we usually begin and end with wages. But terms also covers how your labor can be used; what the company does with it.
I could have worked for defense contractors, and repeatedly chose not to. I don't want my work to fuel war and genocide. We can set those terms, together.
Wow, tech oligarchs are really getting tired of our* shit**, huh?
We have so much power. We would win that fight every time, almost immediately, if we can just stop pretending we're somehow above being merely labor.
*software developers, defined broadly
**expecting to have a say in the terms and conditions of our work
A bit of unsolicited advice for executives everywhere: try not to create a work environment that people are relieved to be fired from.
Apropos of things happening at my previous job.
BTW, if you're hiring for mid-career devops/sre folks, let me know. I can connect you with a couple good and available engineers.
@luis_in_brief That is interesting, yes. And you're right that a solo project may not constitute it's own commons. But it very well could be part of one or more of those myriad layered commons.
You seem to be saying that the lack of existing governance excludes these things from a commons framework. I'm saying that makes them a nascent and vulnerable commons that needs to figure out some governance.
trans lesbianstaff software engineerdevops, reliability, resilience, sociotechnical systemsalso, that gay shitWas @jenniferplusplus
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.