I had an old laptop where graphics worked in the LiveCD installer but not once installed.
Tldr it took a bunch of bootloader config changes to make it work again
Natanael
joined 8 months ago
On Mastodon, your instance doesn't receive posts until somebody on your instance interacts with the account posting it (following the poster, browsing directly to the post, etc).
Feeds with recommendations requires fetching stuff in advance to not be slow and janky. Basically the feed service would need a bot account on your instance and retrieving all popular posts, given the current architecture. Having thousands of these bots across every instance do this would cause a significant performance hit on smaller Mastodon instances when one of their users posts something popular. So you need something different, like a server plugin where the bot fetches the content once and tells all participating Mastodon servers about their cached copy, so they don't all have to hit the hosting instance. But that's a security risk with the Mastodon design.
Doing it this way is why small instances gets hammered when a user's post goes viral.
And as for moderation bluesky also carries information with the top post from the post author and allows hiding replies too, etc. This gets enforced on the appview side, so the posting user's PDS is unscathed if it goes viral.
Bluesky is built to assume a handful of big relay (remember that a relay can merge in contents of another) and a bunch of appview and a ton of PDS servers, feed generators, moderation labelers, etc.
Realistically, the relay network will likely end up voluntarily adopting a tree topology - hobbyist communities would run small relays bundling all activity from members' PDS servers, then a larger relay in front gathers everything from a ton of smaller relays and makes it available to appviews
Zeppelin.social is 3rd party appview and you can host your own
https://whtwnd.com/bnewbold.net/3lo7a2a4qxg2l
A Full-Network Relay for $34 a Month
Add using DID:Web and you're now fully self hosted
No it doesn't. If other people on bluesky servers want to see your content then obviously it will go through bluesky servers, but if you connect to a 3rd party relay and use a separate appview like zeppelin.social and use DID:Web for account ID then nothing involving the bluesky servers was used and it still behaves like native
They fixed the large cache needed to validate all traffic on your own relay. Now the cost is mostly bandwidth and whatever CPU power you want to spend on indexing
The PLC registry is the only such thing, and also it's not a blocker because you can use the DID:Web scheme to manage your own account identity
Content addressing means you can make your instance pull from both their relay and the bluesky relay and trivially merge threads and views without consistency issues, so that's solvable.
The bigger issue is all those other regular users who doesn't, and still get confused (unless they manage to pick a client app that does it for them)
It's doable on Mastodon but significantly more complicated.
You need crawlers to index posts across the Fediverse (and avoid getting them blocked), personalized recommendation models per user, and you need pre-emptive caching on the user's instance for anything recommended (ideally the crawler would make a cache on behalf of each of the opted-in users' instances, but without content addressing this is a security risk). You also need to poll for edits / deletions.
Private posts is planned, but it's not trivial. Mastodon can't exactly brag about their nonintuitive technically just not broadcasted posts, where multiple implementations keep making private messages publicly discoverable due to bugs.
The pens are also very consistent with each other, despite different angles. Probably Photoshop