Natanael

In Sweden the banks offer a choice between an app and a hardware token. You can just go with the token then.

Do you know how certificates work? I do. I run a cryptography forum. Expiration is the simplest of the mechanisms in certificates (it’s just a date stamp and time limit rule) and it’s 100% perfectly predictable what it will do.

If you have it through work you know what to do

If the licensing mechanism is the same then it will in fact happen due to expiring certificates (I have not checked if it’s the same)

Random plug for Matter, which is adding casting support while being open

https://gabellioni.com/matter-casting/

Still under development but there’s already clients and servers available and you can run it on a Raspberry Pi hooked to your TV just fine

“'A lie is halfway round the world before the truth has got its boots on”

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

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.

No, PDS federation is fully open now.

They’re also actively supporting development of 3rd party appviews and relays.