is this mf fortune cookie calling me a liar

@julian are you sending accept application/json or accept application/jrd+json instead of accept application/activity+json?

@puppygirlhornypost2 @thisismissem @julian more generally, the concept of an "instance actor" isn't well-defined

what most softwares call an "instance actor" is really more of a proxy actor, used primarily to sign fetches, not necessarily representing the service itself. i don't know why you'd want to discover such an actor outside of an http signature processing context. if you wanted to have a Service actor it would probably be best exposed via a specific link relation or rdf/jsonld predicate

@thisismissem @julian this assumes that the base url is the instance actor, which it might not be

@julian yeah, A owns the user account on A, but B might have a separate user account on B. the same logical person might control both user accounts. if identity was federated, the same credentials could be used to sign into both user accounts equally.

in other words, imagine identity server I, which is used to sign in on both A and B.

you make a post P1, which is published as R1a on A, and R1b on B. what participants need to know is that both R1a and R1b are authentic.

@hugh @skyfaller ah yeah, in a socialhub thread i called it an “impedance mismatch” and i mostly stand by that — fedi wants to do more than just sending notifications to inboxes, and reading notifications from those inboxes.

the other side of this is that the notifications themselves are often consumed as JSON-RPC instead of being kept around as bona fide resources. when’s the last time you stored a raw HTTP POST request/response message on disk? all fedi cares about is side effects…

@julian @smallcircles i think i may have said this to you before, but the precise pain point is less “i had to go to another website” and more “i can’t do anything on that other website”. the web is by design already federated in a sense, but we have built a second-layer nested/virtualized browser-within-a-browser. https://www.devever.net/~hl/webappcoupling

@julian @strypey one wonders if it would perhaps be more expedient to just do the identity bits and have the data live on B rather than ferrying it back to A.

probably what’s needed is a framework for tracking which resources are equivalent to each other. say i crosspost from my website to a forum. the post exists as two resources, one on each site, even though they are the “same” post. maybe as:alsoKnownAs can help here?

@hugh @skyfaller here, the AP server handles storage and delivery. i could then use mastodon/pixelfed/etc as clients to GET/POST against my outbox/inbox as needed, basically treating the AP server as a database of sorts, as well as a mail server of sorts.

most implementations of fedi are not like this and do not want to do this. they want to be monoliths. monoliths are “easy”. the will to abstract away social activity storage and delivery is largely not there.

@hugh @skyfaller part of the problem with how “underdefined” it is, is that we’re not talking about the big picture being there but mostly in need of filling in the gaps. we’re talking about “there is no agreed-upon authorization framework” levels of “underdefined”.

the other part is that it presupposes a wildly different topology than what fedi adheres to. the most natural interpretation of “client” is not something like Tusky. the AP client would be Mastodon itself as a client of an AP server

@silverpill @julian i was going to say that yes, to/cc/audience are more specific versions of target, specifically audience targeting. not sure Announce.target is needed here... what would be ideal is if multiple Announces existed, one for each category. an AP Announce represents a "share" and not necessarily a "reshare", so it's not like one of them has to be the "original"; they can all exist at the same tier.

@julian example using foaf and sioc...

```
id = f1
type = [as:Service, sioc:Forum]
as:summary = "Forum TF category"

id = g1
type = [as:Group, foaf:Group, foaf:Agent, sioc:User]
as:name = "AP Forum Task Force"
foaf:member = [Julian, a]

id = t1
type = [as:Collection, sioc:Thread]
as:summary = "Some thread"
sioc:has_container = f1

id = p1
type = [as:Event, sioc:Post]
as:name = "Meeting on April 2025"
sioc:has_container = t1
sioc:has_creator = g1
as:attributedTo = g1
```

@julian i think ideally this would be explicitly signalled which objects represented a Feed or Category or Forum or Account or User or whatnot. but the question is how to get from here to there...

@julian posting into a forum could be done with Create, and sharing something to your profile could be done with an Announce of your own object. you can't really tease the two apart. imagine a world where *every* actor published Announce Object. they are in some sense "sharing" the object into multiple contexts and each individual "share" can be tracked in the Object.shares collection

@julian in common usage maybe not, but more generally then yes absolutely

i think the "category vs user" split can be rethought wrt actors, because as stated earlier the difference between a blog (category) and a forum (category) is basically nothing. you could just as easily treat every AP actor as both a category and a user; they are a user when they post and they are a category when you consider their posts. the thing is, right now, some actors primarily use only Announce, some use Create...

@kichae i mean they're all actors as far as activitypub is concerned. what is a blog, if not a category by a different name?

@julian or, rather, if you stretch the concept a little bit, every outbox could represent a "category", just with unknown rules

@julian one thing to watch out for is that not every Group represents something that can be mapped to a category

@julian @andrew_s @nutomic btw there's a reason that section of as2-vocab is called "context and audience"... they are sister properties. one scopes by purpose of when it should be seen, the other by intent of who should see it. (this is also why the rationale for fep-7888 uses the phrase "purpose and intent" when talking about why not use a tag)

@julian @andrew_s @nutomic being part of multiple audiences has always been possible, it's just rejected by overly strict implementers or unhandled by naive ones