@silverpill @steve @raucao The only thing I can really suggest is dropping the use of the prefix mechanism by undefining the `as` term, then rewriting all other term definitions to not use the `as:` prefix. This might make sense since the media type nominally guarantees the meaning of certain terms, and you really shouldn't define your own custom terms in the `as:` namespace, so maybe it's okay to say that no one should ever use `as:`. Is that the resolution you'd prefer?

@silverpill @steve @raucao <Note> is <as:Note> is <https://www.w3.org/ns/activitystreams#Note>, but only "Note" is consistent with compacted JSON-LD.

Fundamentally, identifiers are expressed in different ways depending on context. The prefix mechanism produces compact URIs, which are still intrinsically URIs despite their lexical form not being a valid URI. If you care about referents, you need to expand them.

"as:Public" is canonical for object properties (type:id). Disliking this fact doesn't make it untrue.

smoking weed and getting so high that you start speaking hieroglyphics, call that getting rosetta stoned

@silverpill @raucao no requirements are being changed here. "the identifier is foo" does not mean "the identifier MUST always be expressed using the literal sequence of characters f, o, o".

speaking of requirements, please read the first sentence of https://www.w3.org/TR/activitystreams-core/#jsonld and note the MUST.

"as:Public should be banned" is completely uncalled for.

and you currently need to special-case the full URI too! this is because it is not a real object. the real mistake is addressing Public at all.

@pfefferle @julian @bengo @csarven @raucao @oblomov

i think the context is this github issue: https://github.com/w3c/activitypub/issues/320

was put to the swicg mailing list as a cfc by evan: https://lists.w3.org/Archives/Public/public-swicg/2025Jun/0038.html

bengo requested a clear "error description" and "candidate correction": https://lists.w3.org/Archives/Public/public-swicg/2025Jun/0039.html

to clarify, no requirements are being removed: https://lists.w3.org/Archives/Public/public-swicg/2025Jun/0043.html

i agree that cfc emails should include an "error description" and "candidate correction". perhaps https://github.com/w3c/activitypub/issues/320#issuecomment-2971191447 suffices?

@julian unrelated to the post, but the links to the FEPs are malformed and seem to be missing the https: scheme

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

chat we ripped up some old wallpaper and found under it some even older wallpaper and weird 70s shit

@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 wdym "audience is on its way out"? is this about lemmy not using it anymore?

wrt a Move activity, i think it could work as long as the `actor` was authorized to modify both the current `context` and the new `target` context. i think the issue is mostly in side effects and if/when the `object` gets Updated afterward?

@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
```