For those unfamiliar with DoIP:

https://automotivevehicletesting.com/vehicle-diagnostics/doi...

https://www.iso.org/standard/13400-2

What a pity that some major news publishers have taken to blocking the Internet Archive's Wayback Machine.

The Electronic Frontier Foundation set up a resource page for this:

https://eff.org/age

Their guide:

https://www.eff.org/files/2026/04/09/condensed-age_verificat...

Unfortunately, their most prominent call to action doesn't seem to address the various state-specific and non-US legislation (focusing on KOSA instead). Here it is:

https://www.eff.org/pages/help-us-fight-back

The EFF has long been a skin suit my dude, they're just here to dissipate and confuse opposition.

>they're just here to dissipate and confuse opposition

What do you mean by this?

Interoperable identity providers would indeed be useful.

Beyond that, maybe resilience when a project's host disappears, changes its policies, or gets blocked by a government?

How does tangled solve that? Repository contents are still hosted by the forges themselves.

I was addressing the question of a use-case for a "federation of forges". Not any specific design or implementation.

That sounds more like you want better decentralization, like IPFS or BitTorrent, not necessarily federation between different forge instances. I'm not familiar with any existing federated system that would be resilient to government censorship. Certainly Mastodon and Bluesky aren't.

> I'm not familiar with any existing federated system that would be resilient to government censorship.

Usenet and Matrix are notable examples.

Usenet is, Matrix isn't. Usenet achieves this with a broadcast design - every node on the network receives every message. As a result of this and being flooded with half a petabyte of new messages per day, there are approximately 3 (three) nodes (all other providers are reselling access to one of these).

The text side of Usenet is healthier, with a few gigabytes per day, and not trying to retain every message forever. Would it work if it was also the world's git forge though?

> As a result of this and being flooded with half a petabyte of new messages per day, there are approximately 3 (three) nodes (all other providers are reselling access to one of these).

You seem to be referring to a particular set of binary-focused servers. I am referring to the protocol and network design, as an example of a federated system offering resilience.

(Also, I think your numbers are wrong, but I won't quibble about those because it's the network that's relevant to this thread, not the way some people happen to be using it today.)

> Matrix isn't.

It is. Blocking or shutting down any node in the network only affects that node. Others carry on without it. Another example of a federated system offering resilience.

I haven't used it, but it caught my attention when I read the Text Rendering section of this post:

https://zed.dev/blog/videogame#text-rendering

It looks like their approach could nicely solve a problem that's shared by almost every new GUI toolkit I've tried: text looks terrible, or at least out of place when surrounded by applications built with the desktop's native toolkit.

> I wish GPUI could become the go-to Rust UI library and not just an editor backend.

In case you find it useful, I recently stumbled upon this project:

https://github.com/longbridge/gpui-component

"UI components for building fantastic desktop applications using GPUI."

I took a look at gpui-component a while ago when assessing GPUI for a project I was working on. IANAL but was dissuaded because it's almost certainly not compliant with the Zed license--gpui-component "borrows" gpui code patterns lifted straight from the main zed repo, which therefore must be AGPL/GPL (unlike the gpui-only which is Apache IIRC). Caveat emptor (caveat user?).

I think it was even featured and praised in a recent zed blog post

Gitlab's interface makes me want to cry every time I have to use it. I would not recommend it to someone who misses classic GitHub. Codeberg/Forgejo/Gitea would be a much better match.

What, cause it is too busy?

I haven't made a comprehensive list, but off the top of my head:

- frequently needed navigation links buried within menus within other menus

- menus labeled by mysterious icons, sometimes with mysterious text, sometimes with no text at all

- authentication system that has failed me in a variety of ways over the years, even locking me out of an account in one case

- client-side script execution required to do anything all, even simply display a file

As I said, I haven't kept a list, but GitLab is very much in the category of interfaces that were built by javascript fanatics who don't understand (or don't care about) ergonomics or privacy. I accept that not everyone is bothered by its many problems, but I avoid it when I can.

> The ugly addressing? It “provides solutions to certain problems and is ugly for good reason,” Betanov explains. “Make it less ugly, and it immediately loses functionality. Thus, the solution is not to make addressing nicer, but to hide it from the user,” something both internet email and X.400-powered software could easily do with headers, not so much with addresses.

Reminds me of IPv6. ;)

> its just waaaaaay easier to distribute a web app

Let's also remember that it's infinitely easier to keep a native app operational, since there's no web server to set up or maintain.

No DNS, no DDOS, no network plane, no kubernetes, no required data egress, no cryptographic vulnerabilities, no surveillance of activity... It's almost like the push for everything to go through the web was like a psyop so everything we did and when was logged somewhere. No, no, that's not right.

I have spent a good deal of my life writing software to put food on the table. I didn't interpret any of what he wrote in the way you describe. Perhaps you could explain why you did.