DDG has email aliases?

Ah, sorry. I remembered you having a bunch of Stable Diffusion communities, so I thought maybe such thing might fit your vibe

I think that the guys at lemmy.dbzer0.com might not be against it

Although, I think one community containing all the feeds you are interested of might be a little bit too personal for a general population instance. It might be better to set up your own instance, with just one community and join it from the account you use

There is also ibbit.at !meta@ibbit.at but with that one, I guess you will have to ask for separate communities per feed and the admin does care about the type of content it would be pulling

have it identified

By whom or what?

Maybe some from !fuck_ai@lemmy.world would be interested but I guess it should be another community, just for that

With AP does the exchange have to be http requests? If every instance had a stream instead, would that break the protocol?

With decentralized AT, who would be maintaining the stream? On the image I don’t see a connection between the alternative firehose and right-side pds’

From the looks of AT, its farily linear because its really just operating on a set of giant event streams (like kafka).

Wouldn’t that mean that this stream will have to scale horizontally?

Yes, but those could be just “read instances” spinned up by a peak in requests at load balancer. Not running all the time

It gets DDOSed because after the boost, all the subscribers’ instances are calling it to retrieve the content?

Do you think a load balancer might help?

But is that a limitation of AP?

As far as I understand one could split a fediverse instance into three parts: data, backend and UI. The data is not shared 1to1 - each instance gets a copy of the activity and from that creates it’s own copy. Hence the same post on different instances will have different id The problem we are speaking about is the capability of the backend to process incoming copies. Meaning, I also understand that the part that serves the local data to UI should not be the problem

What if there was a queue at the front and from the backend a scalable ingestion worker would be split off? Those would only do the putting the actions onto the data. Probably with per community(?) FIFO topics/partitions, so we can process data in parallel and not worry about an updoot for a post that does not exist yet

Those would still be fairly easy to deploy and be vertically scalable, right? Or is there some bottleneck in the protocol itself?

ActivityPub works fine now because the community is fairly small, but it will reach its limits as it is currently designed. Its basically an event driven model vs a push and pull model. Sure a docker image can more or less jusy be deployed, but that simplicity is a ticking time bomb.

You mean that when there’s more traffic, the instances will start to DDOS each other?

I can see how that could be a hassle on nixos and if you don’t have more scripts

FWIW, I use chezmoi for stuff like this, I guess it might be easier to make it work with nixos by setting up chezmoi in HOME, instead of defining scripts directly

At this point, I would make it a bash script and put it in ~/bin. If one has to get back to it 5 years later, it will be painful to debug

Now I’m curious :D. Did joining a few communities help or something more was needed for the federation to start?

Shouldn’t it be enough that you join a few communities from other instances on yours? The point of AP was that it could work even if everyone had their own instance, so I think federation should be kicking in more or less by itself, without admin intervention

For music recorded via microphone, Ardour+Hydrogen

For music created more synthetically LMMS

Jack is the way to go. Save yourself the frustration and use it from the start

DID as a permanent, global ID you own, independent of any server

So there would have to be another server, hosting my identity? Would identities somehow be federated between identity instances?