Notices by Julian Fietkau (julian@fietkau.social)

@dansup I've seen conceptual talk of combined ActivityPub servers and AT PDSes. For decentralization, that certainly makes more sense than routing everything through a single bridge. The idea seems worth exploring.

It does have lots of caveats though: posts published to Bluesky cannot be edited and are always fully public, the data model (e.g. 300 chars max) is strict, and there may still be restrictions on the number of accounts per PDS. So check your assumptions carefully.

@StryderNotavi @mekkaokereke @ohmu Indeed! Here are my thoughts on it: https://github.com/pixelfed/starter-kits/issues/1#issuecomment-2475154658

It is an opportunity to prioritze safety where Bluesky decided not to. If someone puts you in a Bluesky starter pack, AFAIK there is nothing you can do about it, and I hear occasional reports about starter packs being used as a harassment vector over there.

@mekkaokereke @ohmu Dan's proposal seems to be geared towards server-specific starter packs to let newly registered users get a richer start. I'm trying to find out in the GitHub discussion if we can merge his ideas with mine.

Of the five ActivityPub starter pack projects I know (there may be more), three aim for something closer to the Bluesky idea, where people can create and share starter packs whenever. I have guesses who might get there first, but it's really anybody's game at this stage.

I am publishing a small #ActivityPub / #fediverse project: https://fietkau.software/webfinger_canary and @canary 🙂

It is a tiny bot showcasing a split-domain WebFinger setup, where the handle domain is different from the ActivityPub server domain. This is supported by Mastodon and some other ActivityPub implementations, but not all of them.

So this project, aimed at devs and power users, is part test case, part feature recommendation/advocacy. The bot's website at https://correct.webfinger-canary.fietkau.software/ has all the details.

@mro Could you clarify your question? The idea of a split-domain setup is that the ActivityPub and WebFinger domains do not necessarily need to match, so that custom domains can be more easily used in fediverse handles.

@mro Ah yes 🙂 This project was put together to raise awareness about the feature and help platform developers test it. Broken servers will always exist, hopefully I can reduce their number by helping their developers with documentation and advocacy.

@mro @aSeppoToTry To test the split-domain handle on a remote actor, you can look up @canary in your platform and see what handle it shows you. I just gave it a try, see attachment.

It currently shows the wrong hostname. That means it's using the ActivityPub ID to construct the handle, when the handle domain should be coming from the WebFinger result. See my checklist https://correct.webfinger-canary.fietkau.software/#developers or the SocialCG report https://www.w3.org/community/reports/socialcg/CG-FINAL-apwf-20240608/#reverse-discovery for details on how to fix it.

Btw: very cool project! 👍

@mro The actor ID should be the thing uniquely identifying an account, yes. However, in conversations we use tags/handles and not AP IDs, so we gotta construct these handles somehow. Your approach, using the AP host, is equally as idiosyncratic as using the WebFinger host. Both ways exist in the wild – Pixelfed, Misskey and Friendica do it the way you do; Mastodon, GoToSocial and Iceshrimp do it the way I do. I just prefer this way because it lets people use their domains more easily. 🙂

@mro You do a WebFinger request on the AP host domain, and its response will give you a subject with the correct handle domain. See for example this account: https://toot.kif.rocks/@team and its WebFinger response: https://toot.kif.rocks/.well-known/webfinger?resource=acct:team@toot.kif.rocks This is a Mastodon split-domain setup.

The process is described here: https://www.w3.org/community/reports/socialcg/CG-FINAL-apwf-20240608/#reverse-discovery (step 4 is important for this)

@mro There is a suggested FEP to include the WebFinger resource in the actor document: https://codeberg.org/fediverse/fep/src/branch/main/fep/2c59/fep-2c59.md But I have not seen it implemented anywhere. In the meantime, the hacky approach works and is reasonably popular. 😄

I don't want to push you into supporting something you don't want to support. Just keep in mind that your software is showing different account handles than Mastodon for some users.

Do you want me to add Seppo to the overview table anyway?

@silverpill Thanks, that helps me a bit. So I'd set up my client to send the posts I write to all of my multiple servers, and if one of them goes down I'm still reachable on the others with all my stuff? And the idea is that people who reply to me send their replies to all of my servers, or do my servers synchronize themselves on their own?

Maybe I just need to read up on this more...

@mcc @MrCheeze

@mcc @MrCheeze I'm pretty sure there are people today running ActivityPub profiles on redundant servers or using distributed identities, but I have yet to understand how that works for post availability and retention, like how I would know where to go to read their stuff if the place I know them from is gone.

@mcc @MrCheeze Define systematic infrastructure? Mitra exists as a practical implementation compatible with Mastodon, and it implements https://codeberg.org/silverpill/feps/src/branch/main/c390/fep-c390.md and https://codeberg.org/silverpill/feps/src/branch/main/ae97/fep-ae97.md. So you can divorce your identity from your AP instance today if you like. I just don't fully understand what that gets us.

If you decide to take your Bluesky PDS down, does their relay keep serving cached copies of your posts forever? Is that a good thing, do we want that?

@morph 😄 This is pretty deep in the weeds, no worries at all if you're not the target audience!

@Edent Good writeup! To add: originating servers could orchestrate anonymous (on the poll author's side) voting by sending votes from a shadow account instead of the user's real account, moving the knowledge of who voted from the pollster's server to the answerer's. On the fediverse, identity is cheap anyway, so there's not much added potential for abuse. @rimu recently did just that in PieFed, in the context of link aggregator votes.

I finished another #webdev side project and built the QR code generator of my dreams: :fietkau_software: https://fietkau.software/qr

* It's instant, purely client-side, and has no ads or upsells.
* It has a variety of color, shape, and logo embedding options.
* There's PNG and SVG export.

The included logo selection is, let's say, "opinionated" and features lots of familiar faces if you enjoy federated social platforms. 😄

Here are a few example QR codes that all lead back to my Mastodon profile.

@evan An added dimension is that there are some fediverse implementations that are indeed server monoliths, even though most are not.

In a pitch presentation I've previously given, I tried to visualize the differences to closed social networks like this. A dot is supposed to represent one person, and Mastodon is more of a nebula than a single unit.

I'd be open to suggestions for improvement. 🙂

Edit: The next post in your thread has the improvement ideas. 😄 I'll take that on board, thanks!

@tchambers I've been working on multiple projects with it, it's enjoyable.

I don't know the whole Node / other server side TypeScript ecosystem very well, but Fedify with its documentation and examples makes it pretty easy to get started.

Also you messed up your cc. 😉 @hongminhee

@evan I would love to try poutine in this lifetime. Apparently there used to be one single restaurant in this city that made it, but it closed down a few years ago. Gotta hope I can find an opportunity while traveling.

@hongminhee Does it assume that? I don't see it clearly stated in the documentation that the IDs themselves need to be numerically sortable, just that, when given a specific ID, the server needs to be able to retrieve newer or older posts based on it.

Of course sortable snowflake IDs make implementing this easier on the server side.