@helge hmm, looking at @hollo getting a 66% for addressing, and tbh, no one should support just “Public" instead of “as:Public”, unless “Public" is aliased in the @context.

I'd actually be inclined to decrease scores for supporting “Public” without “as:Public" or the full URI.

@thisismissem @helge @hollo "Public" is actually invalid and should be treated as a relative URI (check how things compact under JLD)

@erincandescent @helge that's why I'm suggesting that software that supports it should actually be down-scored. i.e., it's a negative behavior not to encourage support of.

Same with inReplyTo with an invalid actor.

@thisismissem @helge inReplyTo with a Link object as well IMO

(Maybe AS2 permits it, but this is insanity and nobody should ever emit it)

@erincandescent @thisismissem @helge but what if you actually are replying to a link? as in, something with no linked data representation

@erincandescent @thisismissem @hollo @helge we need a vocab-relative term like `visibilityClass` or something specifically defined as `type:vocab`

This is meant as informative on what is possible. If these things should not be possible, get the specifications updated.

@helge @erincandescent @trwnh

I don't know about that approach.. The spec is so loosy-goosy that pretty much anything goes.

Just because it's possible, doesn't mean we should recommend it.

Like sending a Flag with a single object, possible by spec, but Mastodon will fail to handle it.

@thisismissem @helge @erincandescent i think Flag is not technically specified anywhere as a "report" so mastodon is the de facto here. they ideally should handle flags of single objects, regardless of what that object is. i'd also say evidence should be attached via `attachment` but i don't think mastodon will handle that either

anyway, replying to erin: replying to a link is something that i don't think is "insanity". it might not be ideal, but if you want to describe something undescribed...

@trwnh @helge @erincandescent there's work in progress to specify Flag further, but my point was more: the spec leaves the door open for pretty much anything. Not all of what it ends up allowing actually makes sense.

@thisismissem @helge @erincandescent sure, but i’m saying that some things that are claimed to be nonsensical in some cases actually do make sense in other cases. like replying to a Link. or Flagging a single object.

i mean i guess you could use a non-authoritative object representation for some resource instead of using a Link, but that raises trust issues

@trwnh @thisismissem @helge I guess what I'm trying to say is less "you should never do this" and more " you should not do this in the normal case"

A Link pointing at an Object is stupid

@erincandescent @thisismissem @helge counterpoint: a link-sharing service that models a link as Link

it's just a little silly to say that any valid expression is "stupid" if someone somewhere can find a use for it. now, sure, there are *patterns* and *best practices*, and we should work to document those, but semantics and language are notoriously flexible...

@trwnh @erincandescent @thisismissem @helge it always comes back to being strict about what you produce and liberal about what you accept

Yes!

I do not know what I exactly expect. But let's consider an example. Say Alice send an activity addressed to me (so I'm in the to list) and my server cannot parse it. What should happen?

Current behavior: The message gets silently dropped. Should there be a notification mechanism?

@helge @erincandescent @thisismissem @oblomov by definition, the activity *is* the notification (specifically an LDN), and the base case is you just show the raw jsonld to a human. this is probably not the best user experience but it is the minimum. the server's responsibility is only to make sure that it is not malformed JSON, and that any identified side effects are carried out if possible (per AP).

@helge @erincandescent @thisismissem @oblomov example: see https://browser.pub