Comment by lloeki

> So many projects get caught up in the complicated mess of mapping their data model onto AP, debating about how exactly to map things and writing standard extension proposals....

Well, you either use an existing standard so you can federate with existing implementations, or you come up with a new standard and ask others to implement that. Seems they chose the simpler way, thankfully.

> Useful federation between Forgejo instances could be solved with little more than OIDC and a few webhooks (cross-instance collaboration, forking, and PRs).

What about federation between more software than just your own? Once you've done those things, you basically end up with another spec (but informal instead of formal) that others also need to implement. So instead of going the informal way, they aim for the formal one. That does sound appropriate to me.

Slightly besides the point, but for someone who dealt more with decentralized/distributed systems than bloated authentication systems, it seems both simpler and easier to map+implement ActivityPub than implement OIDC+"a few webhooks", but that might just be because of my familiarity.

I'll say that ActivityPub is a pretty simple standard though, compared to what's out there.

I tend to agree that ActivityPub seems pretty horrifying to work with (as an outsider). At least it works, though, and is implemented by a large amount of different projects and not owned by any single one.

> Useful federation between Forgejo instances could be solved with little more than OIDC and a few webhooks (cross-instance collaboration, forking, and PRs).

That would only solve the problem of "I don't have an account on this forge yet". The much more relevant problem is identity + reputation. With ActivityPub-based federation you can use your domain-bound identifier to contribute to various projects across servers and gain reputation and trust. If we use OIDC, then it is a lot less clear if the server, you authenticate with, is hosting the real franga2000.

It's already awkward just between Lemmy and Mastodon.

I guess Lemmy could be in the form of issues on the repo and Mastodon would be thumbs up emojis and/or "starring" the repo.

Yeah I wish there was a different protocol if we are jamming everything on top of it.

FYI: Just last Friday there was a call/meeting to coordinate and build out the federation efforts in Forgejo. More work is coming and more help is appreciated! There will be a presentation at FOSDEM on this topic and there is a matrix room dedicated to Forgejo Federation.

There's value in quickly browsing files of a project without needing to clone it first -- especially for quickly linking others to specific lines, API docs linking to implementation, etc. That needs to expose content at every commit, for stable links. So, some sort of a "web git viewer" is very useful.

Unfortunately, the more minimal read-only ones have ended up with far worse UX than the Github clones, or are a scary tangle of shell scripts and/or C. :-(

(Anyone want to collaborate on a Rust-based read-only git browsing web UI that aims for great usability? I'm all in, I want one. I know how to make it handle search etc, I'm not great at wrangling CSS to will or getting navigation right.)

I suspect the reason is the same as the use of local git GUIs and TUIs; git has a terrible CLI, so everyone uses its plumbing, but not its porcelain.

I needed something like this 16 years ago at work to manage shared code, tickets, and code review of private code across a team of engineers. Code review for formal quality assurance was the most important need. I started with trac, then Phabricator, then GitHub enterprise. I just checked out git appraise to see how my nuclear and mechanical engineer friends would like it, and from what I see, I'm guessing they would not. We were using eclipse back then so maybe if that eclipse UI plugin still works it could work.