In something that may surprise a whole bunch of people, the notion of an "instance" is something of a lie.
Instances don't technically exist: https://www.w3.org/TR/activitypub/#server-to-server-interactions
In something that may surprise a whole bunch of people, the notion of an "instance" is something of a lie.
Instances don't technically exist: https://www.w3.org/TR/activitypub/#server-to-server-interactions
@thisismissem true
It's just a side effect of everything having addresses via id and url properties, and the Host header in HTTP, as far as I can tell.
The notion of an "Instance" isn't one that's actually codified in the ActivityPub specs. Instead you just have Actors, and the "domain" of an actor is simply the hostname of the actor's id or url (iirc)
It's only things like Webfinger and HTTP Signatures that bring forward this notion of an "instance" being a "domain" into existence
@thisismissem I'd say `sharedInbox` would be just the teensiest hint of the instance as an entity.
@thisismissem I'd say the whole thing is a Service.
@evan yeah, I'd argue that we should probably formally define an "instance" or "server" within the context of ActivityPub, and that'd be an Organisation or Group Actor?
And then it'd identify it's "instance actor" as a Service or Application?
@lanodan right, but even then you follow through the other related specs the notion of an "instance" there isn't exactly a thing. You're doing a webfinger to the host that's the domain in the handle, but that resolves to something near analogous to an Actor.
@thisismissem That's a very good question!
@evan I guess it depends exactly how you look at it, for a community, is it really a Service? i.e., are we defining the software or the community?
@navi GTS enforces Authorized Fetch by default, which is not covered by the standard. Nobody is compliant. =)
@lanodan @clacke @navi that's a MAY reference to a non-normative section. So basically a "idk 🤷🏻♀️ you do you"
Which is why a spec profile is SO important
@thisismissem n.b.3 i'm kinda sad we ended up with HTTP Signatures instead of something better, I wanted to do something with OAuth2 which I still think would have been cleaner in practice
@thisismissem Truth, the only notion that the core protocol has of "instances" is in origin checking of received messages
(basically: don't trust a message authenticated as https://example.com/@user to contain valid contents for any posts outside of scope of https://example.com/)
(n.b.2. this is also why you can't take "your" keys with you; having per-user keys is also a lie, and kinda pointless, and we could probably simplify the protocol if we didn't have them)
There's maybe also the note here that the origin server remembers that "block" and then if new requests originating from Actors on that domain come in, it just silently drops them.
For User Domain Blocks, even in the case of "DM's" or mentioned-only posts, the post still gets created in mastodon, but the thing that doesn't get created is the notification that the post exists.
When you block a domain globally for a server, what's actually happening is that your instance:
• stops sending new activity's to that domain
• sends out Undo Follow activities for each follower that was Accept'ed from actors on that domain, and
• sends Reject Follow activities for any pending follow requests from actors on that domain
That's it. That's what happens.
There's debate about whether a Delete Actor activity should also be sent out.
@jdp23 @erincandescent right, exactly Jon, so at protocol level they "don't exist", basically my argument that I'm trying to get to is that maybe, just maybe, given the structure of today's Fediverse, a notion of "instances" or "servers" _should_ exist?
@erincandescent@queer.af Great perspective -- and great thread @thisismissem@hachyderm.io.
That said, I look at it somewhat differently. Instances most definitely exist, it's just that they exist in spite of the AP protocol mostly not acknowledging them.
@evan @thisismissem Threadverse instances (lemmy, kbin, piefed) return an Application actor if you GET their root. e.g. attached screenshot.
Mastodon does not. Maybe it should!
The Application is a fully fledged actor, even with it's own public key so it could sign activities it sends, theoretically. I've not seen that happen in the wild, tho.
@smallcircles @jdp23 @thisismissem @bonfire I think the thing to remember is that without protocol evolution so radical it almost ceases to be ActivityPub, instances will continue to exist
So building better community structures and reifying the protocol-level structural entities that exist are both important things to do
@jdp23 @erincandescent @thisismissem
Guess it depends where the general focus is in the developer community wrt protocol evolution. If the general trend is "it should work with Mastodon installed base", things likely will go much slower.
More devs willing to tread new grounds, explore new app types, build libraries, plug holes and take time to bring this to docs + specs, may speed things up quite a bit.
PS. I like @bonfire with federated groups, circles and boundaries: https://bonfirenetworks.org
I agree that communities are a useful concept and that it's very unfortunate that instances are the only community-like mechanism in Mastodon (etc). But I also think that instances are distinct from both cross-instance communities and instance-local communities. For one thing, local-only posts are currently the only enforceable way of limiting post visibility and I don't see that changing any time soon.
@smallcircles@social.coop @thisismissem@hachyderm.io @erincandescent@queer.af
@thisismissem @jdp23 @erincandescent
Instances/servers are this more technical and non-intuitive concept. If we talk about inter-connected communities, why not model Community as an AP extension? In 2021 in context of Federated Groups discussion I advocated for a "Community has no boundaries" paradigm, that is more in line to community as we experience it offline. Recently brought it as a #FediverseIdea: https://codeberg.org/fediverse/fediverse-ideas/issues/47
And nothe there's also Unbound Group FEP: https://codeberg.org/fediverse/fep/src/branch/main/fep/2100/fep-2100.md
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.