@julian (i am vacillating between "everything is probably an article by definition" and "practically speaking nothing too bad happens if we just call everything a note" and "we really should have just been using activities all along" and "just call them posts ffs")

@julian hot take, we should all just use sioc:Post and sidestep the entire debate

@julian i don't see why "500 characters" should matter for this tbh.

@julian @darius Hugo does the same by default, taking the first ~70 characters to the nearest word boundary (or something like that).

i'm just pointing out that there might be some needed disambiguation with how `summary` is used, to account for this kind of "excerpt vs subtitle", "duplicative vs additive" usage.

@darius @julian @technical-discussion one thing this suggests is that there is a semantic difference between "summary" in the sense of providing a short blurb that is additive to the content (kinda like a subheading!), vs "summary" in the sense of providing an excerpt to be used as a kind of preview (as in a list of articles)

@darius @julian @technical-discussion interestingly https://indieweb.org/post-type-discovery#Algorithm suggests that you check if the `name` is a prefix of `content`, and if it is, then it is a Note. perhaps similar logic can be used to check if `summary` is a prefix of `content` in some way?

i don't think this is particularly *wrong*, as generating summaries from excerpts of content is a common pattern in e.g. static site generators like Hugo. it is indeed duplicative, though!

@julian @nutomic for example, some impls attach replies even if they do not share the same context, as a compatibility measure. that kind of stuff

@julian @nutomic i think it's unavoidable that at some point you will end up having to recognize that two context ids may be equivalent, perhaps with one of them being canonical. "cached representation of remote content" is fine and there isn't necessarily a problem there. it depends on how much you embrace the idea of each publisher being allowed to make their own claims (and how much you allow "clean up" after the fact)

@julian i am still kind of confused what this fep adds over 7888 which already describes ownership and inheritance. i guess upgrading some SHOULDs to MUSTs? which i don't think are actually MUSTs in practice... any missing info can be skipped over.

@julian hi! following up on this, were there any minutes from the meeting?

@julian i'll try to make it but i am very tired right now recovering from my first-ever covid infection, so there's a chance i won't be able to make it

@quillmatiq @julian personally i find that interop can lead to worse UX if you have to compromise on your own experience to be compatible with someone else's assumptions. so improving UX might require explicitly breaking interop.

more generally, UX friction can be good, and good UX doesn't imply that the thing is good. putting decentralization first means you emphasize values -- do it right before you do it well. putting interop first means you defer the value judgement.

@julian i don't think interop comes first. what is the goal? if the goal is explicitly to promote decentralization then yes you should define that term first. and decentralization is fundamentally a political goal while interop is fundamentally a utilitarian goal. for example: facebook has 2 billion users, so it clearly has some utility for some people. but it is politically unacceptable for other people, who will oppose it despite its utility. it is shortsighted to prioritize interop alone.

@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