Phantasm

@p @bajax @pwm @f0x @mrsaturday @sun chomp

@john_darksoul @pernia @zero this you?
soyjak-containers-docker.png

@pernia @john_darksoul @zero Doesn't matter that it is packaged when the Docker image doesn't have it installed. There are people that run 5 different Postgres instances on the same box in different containers, because Docker Compost told them to.

@pernia @john_darksoul @zero Nothing, it's a 3rd extension so 99% of Postgres images you would want to use don't include it. You most likely have to build your own image.

@john_darksoul @zero Run a Postgres DB in it and try to use pg_repack.

@silverpill @sendpaws
>Why it is a useless traffic? On the contrary, embedded signatures reduce traffic because relayed posts don't need to be fetched from origin.

Take peer lists from mstdn.social and mastodon.social, filter for the same peers, cut them by an arbitrary fraction like 1/3 to somewhat compensate for dead instances and that number is the number of requests that are useless because both instances sent the same posts to the same instances. Now expand over the whole network. At least that's what happens when you implement shared inbox delivery relaying the way AP tells you to. Traditional relays don't have this problem because an instance subscribes to only a few of the large ones, one or two; treating an Announce with a pointer and a relayed Create or however this works the same.

For there to not be swaths of completely wasted traffic, you have to reduce the trigger for relaying to only a few actions, and never trigger when you receive a POST for a remote post.

>Federated groups (FEP-1b12), conversation containers

These don't inherently need it. They only need it because they embed Activities for real federation. Which is a valid case at least.

>nomadic identity

It doesn't matter here because the gateway can still rewrite posts and resign with its own key anyway. You would have to eliminate the middle man gateway and turn it into a Client-to-every-Server/Client at which point the proofs aren't needed either since the client is the one controlling the Actor representation now. However NAT becomes an issue.

@silverpill @sendpaws And when would that be useful? When I receive a POST, it has to be already signed. And when I fetch something I have to trust the instance anyway since the instance can easily swap keys for a user, rewrite posts and resign.

Relayed posts (par. 3) I guess, but that is just more useless traffic on the network. When large instances do that, it just creates requests which have no effect on the receivers since they have the posts already from someone else.

@sendpaws @silverpill If everybody stopped toying around with adding stuff that has no reason to exist, things like this wouldn't happen.

>Object Integrity Proofs

There is literally no use for this. You fetch an object, you get an object. You check the IDs if they match if you want and the origin and that's it.

>But what if I don't actually trust the instance I fetch the object from? What if I want to relay objects?
<Usecase?

It's gone gone, the data I actually wanted is irrecoverable. Main superblock is gone, replacing superblocks with backups fails with IO errors and btrfs restore can't piece what I wanted together due to zstd compression. Time to restore from 14 day old backups :))

Just in case btrfs rescue fucks it up even more (currently unmountable with a bad superblock 🙃)
cffa0083-2a4e-4b83-a407-638840945b0f.webp

Broke btrfs by testing hibernation award.