Welcome to Incremental Social! Learn more about this project here!
Check out lemmyverse to find more communities to join from here!

@by_caballero@mastodon.social cover
@by_caballero@mastodon.social avatar

by_caballero

@by_caballero@mastodon.social

long-in-the-tooth gadfly, man of the people, and, improbably enough, paid opinion haver

boost-free profile: https://justmytoots.com/@by_caballero

This profile is from a federated server and may be incomplete. Browse more on the original instance.

erlend , to Random
@erlend@writing.exchange avatar

https://socialhub.activitypub.rocks/t/fep-7952-roadmap-for-actor-and-object-portability/4332?u=erlend_sh

I think this is the most important (WIP) Fediverse Enhancement Proposal of this year for the protocol:

FEP-7952: Roadmap for Actor and Object Portability — by @by_caballero and @dmitri

It ties a lot of elementary building blocks for neatly together, most succinctly summed up by one particularly magic feature:

Bring-your-own Actor ID! 🪪💫

Actor profiles can now be hosted separately from the instance (including as a static JSON object (…)

by_caballero ,
@by_caballero@mastodon.social avatar

@smallsees @erlend @dmitri Ideally yes, target state is "status quo", but it's a little unknown how many of today's implementations accidentally hard-code assumptions to the contrary. The reason we worked on a Roadmap first and broke out just the Actor-independent URL part second is to make explicit and testable behavior that should already be possible in ActivityPub's specification of the Actor Object... but maybe not always in practice today.

by_caballero ,
@by_caballero@mastodon.social avatar

@smallsees @erlend @dmitri (also the spec indirectly explains how to build a microservice that could run for $1/mo on a little heroku-style platform you could point myname.com at-- we can hopefully provide a prototype soon and, if people demand it, add more explicit detail about how to build one's own or adapt the idea to other form factors?)

by_caballero ,
@by_caballero@mastodon.social avatar

@smallsees @erlend @dmitri The harder adoption question is finding server implementations that want to give their users this self-managed and more-portable option. It's kinda "power-user only" until there are turnkey services like what bluesky built with namecheap for people to "one click set up" a bsky "handle" (technically, a DID with very similar properties and syntax under the hood if you check it out on github!)
https://bsky.social/about/blog/7-05-2023-namecheap

by_caballero ,
@by_caballero@mastodon.social avatar

@erlend @Crell Great questions-- honestly. As-is, "blocks" aren't a feature of ActivityPub or even standardized enough for there to be one spec I could go update, extend or replace-- it's all pretty ad-hoc at the moment, sadly.

In theory, however, a server would have more options open to them: if they want to apply a phpc.social block against anyone with phpc.social in their Actor object, they could! And a block on crell@crellshouse.com would survive you moving to freespeech.social 😏

by_caballero ,
@by_caballero@mastodon.social avatar

@kiriappeee @fanden @erlend absolutely-- no one likes talking about boring small-business usecases as an adoption tailwind or business driver, but my intuition from working in the identity trenches is that making identity separate from service provision could help drive new kinds of adoption. @pfefferle may have insight here on different headless/whitelabel formfactors 😃

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • incremental_games
  • random
  • meta
  • All magazines
    •