Post AvpneIzzxpZCLJ8oIC by claudius@darmstadt.social
 (DIR) More posts by claudius@darmstadt.social
 (DIR) Post #Avj3srkfmzALLCDad6 by claudius@darmstadt.social
       2025-07-01T21:40:05Z
       
       1 likes, 0 repeats
       
       #Gitlab just closed the issue about supporting #ActivityPub. Kai Armstrong says "our current focus isn't in this area".This is very sad, I really think this could have been a pretty good match *espacially* for Gitlab. It could have been a puzzle piece in how to do federated open source coordination. You know, the problem with "not wanting to be on github, but kinda finding it convenient everyone has an account already".https://gitlab.com/groups/gitlab-org/-/epics/11247#note_2597450590
       
 (DIR) Post #Avk2Hipu4KEkB9Li5I by bzg@floss.social
       2025-07-02T08:35:15Z
       
       0 likes, 0 repeats
       
       @claudius Developing https://forgejo.org seems like a good idea.
       
 (DIR) Post #Avk2HjvxzGgHaFC4Aq by smallcircles@social.coop
       2025-07-02T09:21:26Z
       
       0 likes, 0 repeats
       
       @bzg @claudius And #forgejo already has a level of #ActivityPub federation support, like for federated stars:https://domaindrivenarchitecture.org/posts/2024-06-05-howto-federated-starsHopefully with @forgefed adoption on the roadmap too, where this open standard supported by @NGIZero has been significantly progressed, but needs implementers in active feedback loops to refine and mature the specs.https://codeberg.org/forgejo-contrib/federation/src/branch/main/FederationRoadmap.md#ForgeFed #Forge #CodeForge #Gitlab
       
 (DIR) Post #Avk2HkuENCt2b9OC6j by claudius@darmstadt.social
       2025-07-02T15:02:59Z
       
       1 likes, 0 repeats
       
       @smallcircles @bzg @forgefed @NGIZero I like Forgejo and use it in the form of @Codeberg. But I would still like to get Gitlab to also support the fediverse.
       
 (DIR) Post #Avkcxi252kzACOMhSy by strypey@mastodon.nzoss.nz
       2025-07-03T08:45:35Z
       
       0 likes, 0 repeats
       
       (1/2)@claudius > Gitlab just closed the issue about supporting ActivityPubThey don't want to be leaders, they'd rather be followers (or worse, also-rans). Fine, we can work around them.ForgeFed support for GL could be built as a plugin or a patch, based on any AP code Kik published so far, and adopted by independent GL instances. Once a critical threshold of adoption is reached, the network effects will be large enough that the GL flagship will follow.@smallcircles @DerMolly @bzg
       
 (DIR) Post #Avkd6uFwxulQiTEpDk by strypey@mastodon.nzoss.nz
       2025-07-03T08:47:22Z
       
       0 likes, 0 repeats
       
       (2/2)It would be a great project for a grant application. Especially if a bunch of GL instance admins were willing to commit to using a working FF implementation, and lay out a rough plan for sharing the load of ongoing maintenance of the code.
       
 (DIR) Post #AvoCFlBE9wUH2jrl4a by silwol@chaos.social
       2025-07-03T10:33:16Z
       
       0 likes, 0 repeats
       
       @claudius At @OpenTalkMeeting we use a private GitLab Premium instance. We would like to open that up further, but the GitLab pricing model would require each contributor to have a paid account (~30 € / month), and with the automated account deactivation feature enabled, each account would remain active for at least three months before set to inactive. Federation would have been an escape hatch here, but with this perspective, GitLab is actively blocking involvement in the open source community.
       
 (DIR) Post #AvoCFmZiyLg1N0KptY by silwol@chaos.social
       2025-07-03T10:35:37Z
       
       0 likes, 0 repeats
       
       @claudius This course of action sadly confirms the impression that I got when we approached them with regard to that matter. Not interested in small to medium sized company needs, focusing on the large customers only.
       
 (DIR) Post #AvoCFnaTD3rqVbgwhE by strypey@mastodon.nzoss.nz
       2025-07-05T02:05:12Z
       
       0 likes, 0 repeats
       
       @silwol> Not interested in small to medium sized company needs, focusing on the large customers onlySounds like the VCs are already in charge of the asylum. This is exactly the enshittification path GritHub went down. Free Code with proprietary secret sauce ("Open Core") >  VC funding > acquisition by corporate DataFarmers.I still think it's worth developing a ForgeFed patch for those community-hosting CE, based on @kik's AP work, whether or not it's ever used at the flagship.@claudius
       
 (DIR) Post #AvoPuU4dxn1HGZXGim by smallcircles@social.coop
       2025-07-05T04:38:13Z
       
       0 likes, 0 repeats
       
       @strypey there is good news on the ActivityPub epic, as it has been reopened by Gitlab again, for someone to pick it up.https://techhub.social/@kik/114796672444001986
       
 (DIR) Post #Avomp5yKRaNI0tyuAa by kik@techhub.social
       2025-07-05T08:54:44Z
       
       0 likes, 0 repeats
       
       @strypey I don't think GitLab has plugin support, to my knowledge, so it would have to be a patchset, with the obvious usal problem of having to fix breakages happening because upstream doesn't know the code exists, and the other usual problem of explaining to users how to patch their vanilla GitLab, or having to distribute a patched version.**But** it's still an idea worth considering, I think, in retrospect. 😅 Because it would allow to bypass completely the major pain point of contributing to GitLab: being forced to send very small MR, just a few lines at a time, and having to explain again and again to new people reviewing it what the whole point is about and how you're doing it, which causes each small MR to take weeks to merge, and then you have 4 or 5 more to merge because you had to split your feature. For something like ActivityPub that is made of many features, being able to develop the support independantly without this grind would certainly help.
       
 (DIR) Post #AvpneIzzxpZCLJ8oIC by claudius@darmstadt.social
       2025-07-05T19:34:04Z
       
       1 likes, 0 repeats
       
       Sometimes it really does help if a lot of people comment. The #ActivityPub issue was reopened by #Gitlab:https://gitlab.com/groups/gitlab-org/-/epics/11247#note_2603598572
       
 (DIR) Post #Avqnz2QowzsECPX7Ds by strypey@mastodon.nzoss.nz
       2025-07-06T08:16:57Z
       
       0 likes, 0 repeats
       
       @kik > to develop the support independantly without this grind would certainly helpI imagine the work would go much faster, be more exciting (coz faster), and more fun (coz faster and exciting). Maybe easier to get more devs helping too?Re: getting it all merged, it may be that it's easier to get 2 whole elephants onto the GL arc than to MR them on one body part at a time : PI'd be happy to help recruit a few GL instances admins as testers. Here's some candidates;https://wiki.p2pfoundation.net/List_of_Community-Hosted_Code_Forge_Instances
       
 (DIR) Post #AvqowHhpnuuoeok4BM by kik@techhub.social
       2025-07-06T08:27:46Z
       
       0 likes, 0 repeats
       
       @strypey > Re: getting it all merged, it may be that it's easier to get 2 whole elephants onto the GL arc than to MR them on one body part at a time : Pwouldn't it? :) Of course, I'm not the one who decided to split everything in many MR. If you try to merge something big, GitLab will reject the MR, asking you to split it into smaller chunks. Because they take reviewing very seriously, each line is scrutinized and has to be perfectly understood by the reviewer.There are very good reasons for that too. GitLab is used by governments and fortune 500 companies, they have to adhere to certifications, and they can't just YOLO merge randos' code.
       
 (DIR) Post #AvqpvHNjck2HJgQPvU by strypey@mastodon.nzoss.nz
       2025-07-06T08:39:11Z
       
       0 likes, 0 repeats
       
       (1/2)@kik brevity trumps clarity once again : P Sorry about that. When I said;> it may be that it's easier to get 2 whole elephants onto the GL arc than to MR them on one body part at a timeWhat I meant was, if they see the whole thing working between independent GL instances, they may grok it in a way they currently don't. If so, they'd be more motivated to prioritise all the MRs required to integrate it, and maybe put an employee on shepherding the whole lot through efficiently.
       
 (DIR) Post #AvqqJLSy5ck4vyLfE0 by strypey@mastodon.nzoss.nz
       2025-07-06T08:43:33Z
       
       0 likes, 0 repeats
       
       (2/2)The larger point (100% implied) was that the goal is not to maintain a Minority Report of ForgeFed patches for GL indefinitely. But to either get merged into GL CE, or create a full community fork (a la LibreOffice and Forgejo).Either option becomes potentially easier to get buy-in for once there's a working prototype, and the fundamental UX splinters have been noticed and smoothed off.
       
 (DIR) Post #Avqu5klvbeA9BHzVxo by kik@techhub.social
       2025-07-06T09:25:38Z
       
       0 likes, 0 repeats
       
       @strypey it's not a merging priority issue, it's just as slow to merge their own MRs made by their developers. GitLab is a really big machine with hundreds of full time developers adding code to it constantly (if you want to be amazed, go look at the commit history of their main branch and reload it multiple times - well, not on Sunday, though 😅), they have to keep it in check. I'm tempted to say the slowness is a bug more than a feature, for them.I'm all for the idea of having this kind of features as a plugin, should GitLab develop plugin support, but hoping we could bruteforce the all code at once back into the main codebase when the features are complete because they would find it cool is not realistic, I think (they're already very aware of how cool it is). That would be bruteforcing hundreds of thousands of lines of code in, and I would think that would be an infraction to the ISO norms they have to adhere to. If it's a plugin, it stays a plugin.
       
 (DIR) Post #Avs4tchT5KVfKEHdJo by strypey@mastodon.nzoss.nz
       2025-07-06T23:01:36Z
       
       0 likes, 0 repeats
       
       @kik> it's just as slow to merge their own MRs made by their developersYou're in a much better position than me to know about getting code merged into GL.I guess I'm scrying into the institutional thinking that led to closing the issue, kicking off this whole conversation. Being able to try out a working implementation can turn sceptics into evangelists, especially among non-dev business decision-makers. Which can speed the plow in subtle ways, or at least reduce drag.An example;
       
 (DIR) Post #Avs5bOeoen02Vvupyy by strypey@mastodon.nzoss.nz
       2025-07-06T23:09:36Z
       
       0 likes, 0 repeats
       
       (2/2)Both WordPress and Tumblr are owned by Automattic, who have announced plans to add AP. But WP already has it and Tumblr can't even guess when it might happen. Why?Because for WP, all they had to do was evaluate a working plugin, and if necessary, tweak it to bring it up to their standards. For Tumblr they have to develop AP support from scratch.If Matthias' code was a hot mess, WP might have started again, instead of hiring him. But it would still have been a PoC for non-dev managers.
       
 (DIR) Post #Avs6ZapUWv1ndlc3km by strypey@mastodon.nzoss.nz
       2025-07-06T23:20:27Z
       
       0 likes, 0 repeats
       
       (3/3)But as I say, this is all speculative. What seems certain is that testing a working ForgeFed in independent GL instances can happen much faster if a prototype is finished independently of GL. This sounds like more fun for you than the treadmill of write snippet, grinding MR, rinse, repeat.Again I'm speculating, but I suspect a lot of the issues that come up in MRs - especially UX - would be noticed and fixed in the prototyping process. So MR may not be faster, but could be less work.