max-privatevoid

Yes, the relay design is very convenient for PDS operators on a technical level, but it comes at the enormous cost of having to trust a third party with message delivery, or, alternatively, running services that are much more expensive than an ActivityPub server.

> for some ridiculous reason

A ridiculous reason, such as being able to interact with the federated world from my own server directly, and not through a third-party service. Why is the simple concept of going to your own server to interact with the entire network, getting content directly from your friends' servers, and receiving interactions (e.g. PRs) directly from someone else's server such an afterthought in ATProto?

When you say "they can run on a $5 VPS", do you mean that the entire server will be dedicated exclusively to processing ATProto data? I run an ActivityPub server on my $5 VPS that allows me to interact with everyone else on ActivityPub, and that VPS is hosting a lot more services than just that.

> Tangled has been entirely self-hostable since the beginning!

As has BlueSky, as long as you had enough hardware to keep up with the firehose. The protocol heavily lends itself to centralization due to this design. I think this should be obvious by the fact that you haven't considered self-hosting to be the default case.

> In our case, those are org.tangled.*.

I suppose my wording was inaccurate, but this is what I meant by "the entire network". My indexer would have to consume "all of Tangled" instead of the things related to the repos, orgs and people I am interested in. Correct?

> ActivityPub categorically does not make sense here because of how coupled identities are to instances.

I feel like this is more of an inconvenience rather than a dealbreaker. Having to point people to a new account ID on the off-chance you lose your domain seems like much less of a problem than having to deal with ATProto's firehose architecture.

They had the mostly-centralized offering up immediately, and now they're spending a lot of time making the parts easier to self-host one by one. What does that say about the protocol? And I assume Tangled also suffers from the general ATProto AppView problem, where your AppView has to consume all the content in the entire network even though 99% of it is likely uninteresting to you.

Code hosting platforms are probably much more disjointed than microblogging platforms, so something like ActivityPub, where servers only keep track of content that users are actually interested in, would make much more sense. It's a shame that the people working on ForgeFed and/or Forgejo federation seemingly aren't making much progress.

For a federated system they sure talk a lot about their struggles around scaling centralized infrastructure. ATProto seems like it's entirely the wrong protocol for this sort of application.

llama.cpp has done this since forever. I've used other engines including vLLM here and there, and I was quite surprised that many of them don't have this feature. Glad vLLM has it now.

It's just LPDDR5X, standard modern laptop RAM. Sure, it's quite a bit faster due to the way it's connected, but comparing it to the VRAM on a dedicated GPU is absurd, especially considering memory on laptops has been "unified" in this way since forever.

It's properly sandboxed, which is a lot better than Google Play Services on regular Android. Far from ideal of course, but I assume GrapheneOS is built with those people in mind for whom Google is unavoidable.

The last couple of Android phones I bought, I rooted within 1 hour of owning them. The current one will probably be my last Android phone.

It's always been a matter of skill issue. An LLM subscription being necessary or not says more about the user than the tool.

That's the wrong domain...

An XR glasses company, Nreal, changed their name to XREAL, allegedly because of Epic Games.

> ZDR

Does anyone actually believe this?