Notices by Julian Fietkau (julian@fietkau.social)

@joemcken.net Hey from the other side 👋

Mastodon's quote posts require individual permission from the quoted author (this can be set to be given automatically). Bridgy Fed still needs to implement that part. Progress is tracked here: https://github.com/snarfed/bridgy-fed/issues/1956

cc @tchambers

@rimu @hollo @thisismissem @julian@community.nodebb.org @dansup @renchap

I was thinking about letting people pick one color and having the FEP provide wiggle room and guidance for platforms on what to do with it, like e.g. nudging very light or very dark colors for different backgrounds. I think Twitch does something like that for custom name colors.

It'd be up to the theme creators to decide how to incorporate it while preserving contrasts, or which colors can't work at all.

Gonna keep thinking it over.

@hollo @thisismissem Congratulations!

I'm still kind of obsessed with the idea of turning the profile color into a federatable actor property and creating an FEP to let server platforms (and ultimately clients) display people's profiles with visual accents in their chosen color.

It's not MySpace level of customization, but giving people a sense of ownership of "their" space is nice.

Would that be a waste of time or would any other platform want to buy in? @julian@community.nodebb.org @dansup @renchap @rimu

I'm finally unveiling the #ActivityPub project that has been consuming my weekends: Encyclia, an #ORCID bridge that will make ORCID records followable and interactable on the fediverse. 🙂

It's early-stage and the ORCID following function is not publicly available yet. We're seeking community feedback on functionality and safety aspects. Read more at https://encyclia.pub or follow @encyclia for news!

#fediverse #fedidev #scicomm #wisskomm #academicchatter

A cursed #ActivityPub idea.

Problem: Remote profiles sometimes look empty on Mastodon because only the stickied posts are synchronized on profile update.

Observation: Neither the ActivityPub nor Mastodon specs limit the number of sticky posts on a profile. Nothing says you can't have 100 000 sticky posts.

Solution: an ActivityPub server implementation that auto-stickies every single post you write.

The things I come up with thinking about @fedify while in the shower.

@BeAware He'll probably clarify this himself, but just to head it off a bit: @rolle didn't build a search engine or a database, but an ephemeral browser-based display of the public timeline. Bit of a difference in scope (and privacy).

@jedi Thank you! Yeah, I know about Ghost of course, but @fedify deserves more external projects to show off what it can do. I hope we'll see some more come out this year. 😀 Do you know of any others that are in progress? I would follow dev logs if they're out there.

Made a little bit of progress on my #Fedify project yesterday. Spun my wheels testing a few #TypeScript ORMs and running into compatibility problems with each of them. By the time I went to bed, the preferences page was capable of storing and loading account-local form data for the first time. 🥳

For this project, when progress looks slow from the outside, it's because I'm learning the ecosystem pretty much from scratch. Not letting myself get discouraged. 🙂

@tchambers @dansup One issue with that approach is sooner or later (when they want to log in on another device, when they get a new phone, etc.) people will need to know what server they're on. Flagship instances circumvent this by saying "if you don't know, you're almost certainly on this one." It can't be randomly assigned and then never brought up again. If people get assigned to random servers, we need to find reliable ways to make them feel connected to their server and remember it later.

@flancian There are also protocol-related concerns. Setting up copies of existing Mastodon posts on a different server changes their ActivityPub IDs, so past interactions would get lost. So you can't meaningfully "move" posts - that would require them to have decentralized IDs, something that @silverpill does work on.

I'm with you that copying post content should be part of account migrations though. @renchap once mentioned that Mastodon wants that too, it's just not urgently prioritized.

@reiver

(a) My impression from some semi-recent discussions here and on the Mastodon Discord is that there's much more momentum for abolishing host-meta support than for abolishing WebFinger.

(b) My stance on handles is that they should not be used for protocol-level identification of actors (since ActivityPub already has IDs). Resolvable? Sure. Permanent? Nah. Let people change their names and configure custom domains without moving their accounts. https://correct.webfinger-canary.fietkau.software/#developers

@Edent Your example doesn't clarify the origin of Alice's ActivityPub ID.

Handle domains and host domains can be different, yes. See @canary.

Can an actor and objects owned by that actor reside (as in, have their ActivityPub IDs) on different hosts? AFAIK there is nothing in the AP standard that forbids it, but implementations commonly use origin matching to confirm authority over objects. This is codified e.g. in FEP-c7d3: https://codeberg.org/fediverse/fep/src/branch/main/fep/c7d3/fep-c7d3.md

Will you necessarily run into issues? Dunno!

@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. 🙂