@mariusor the problem (for others) is that when you use the same URI to refer to different things, you can no longer distinguish between them. it's why the naive approach is to just use file extensions -- less ambiguity. you can trade content negotiation for explicit identification ahead-of-time. but it's quite tenuous to say that foo.jsonld and foo.png are "the same" in any meaningful sense. one is a description of an image, the other is a representation of the image. neither are the real thing

@mariusor again, this isn't theoretical, there are plenty of web servers doing exactly this.

you can find services of this sort all over the place:

https://placehold.co/

https://picsum.photos/

and many widely-used softwares as well:

https://www.contentful.com/developers/docs/references/images-api/

https://github.com/imgproxy/imgproxy

@mariusor no, i'm just trying to reach a mutual understanding.

content negotiation is fine if you are serving the same information for the same identifier. you have this idea of images being documents, people being documents, etc., and i have the idea that the representations are not the thing itself.

take for example the very popular and common pattern of doing something like this:

/image
/image.avif
/image?width=600
/image/thumbnail
/image@2x

these might all be "the same image" at the end.

@mariusor it's perfectly practical to serve what the requester asked for. it's not very practical to serve something they *didn't* ask for, instead of the thing they asked for.

any http server is capable of this. maybe they use query strings, maybe they don't. there are defaults in any case.

i mean, you probably encounter a cdn serving images like this multiple times every day, without even realizing it.

@mariusor @thisismissem @oranadoz @hongminhee using content negotiation as an example: i can ask for the same Image as either image/png or image/jpg, right?

```
GET /image
Accept: image/png

303 See Other
Location: /image.png
```

or...

```
GET /image

200 OK
Content-Type: image/png
```

the Image is the same Image even if i resize it, or convert it to a different format. we are generally uninterested in reasoning about representations instead of reasoning about the thing itself.

@mariusor @thisismissem @oranadoz @hongminhee i don't think it's cumbersome at all. if people used the as2 data model directly and operated on activities instead of transforming statuses, they wouldn't have that issue (and it is a different issue).

the issue i'm talking about is ambiguity. when you use the same identifier for two different things, you can no longer distinguish between them. this is known as equivocation.

example: does an Image have a width of 800 pixels? no. the repr does.

@thisismissem @mariusor @oranadoz @hongminhee +1, an image and a descriptor are different things and should be treated as different things. content negotiation is not a solution here -- the same information should be returned for the same resource (modulo whichever representation you ask for or receive).

@mariusor @hongminhee > the same URL can represent both

bad idea. an identifier should unambiguously refer to exactly 1 thing

@evan @hongminhee more and more i am thinking that Link was a bad idea from a data modeling perspective. "assume bare href instead of bare id" is something that can never make sense. if we really want to maintain validity of Link then it should *always* be embedded as an anonymous object:

icon: {
type: Image
url:
{
type: Link
href: foo
height: 400
width: 400
mediaType: image/png
}
}

here, Image.url means "representation of the Image"

@silverpill @tesaguri i.e. if org.example/~alice/foo claims to be attributed to org.example/~bob, we don't know a priori if this is true or false. ~bob needs to be able to make a claim for ~alice/foo as well.

ironically, mastodon came up with a relatively more sound solution for fediverse:creator than it uses for attributedTo. their attributionDomains property at least establishes trust for a domain explicitly. (it would be nice to have more granularity though! maybe attributionPrefixes?)

@silverpill @tesaguri checking content-type doesn't actually solve the issue either, because a web server may be configured to serve the "correct" type for user uploaded documents. the real mistake is

> FetchRemoteStatusService#trustworthy_attribution? trusts the attributedTo property of a fetched object as long as the domain of the attributed actor is the same as the original request URI.

attribution is only trustworthy within a trust framework that allows entities to validate existing claims

@evan I don't think it's going to take a long time. If you have a file host you'd like to propose that we can mirror the Codeberg fediverse/fep repo to, then by all means, propose one.

In any case, the lack of availability of a response over HTTPS should not be taken to mean that a context "doesn't work". Newer W3C specs recommend preloading contexts with known content+hashes ahead-of-time: https://www.w3.org/TR/vc-data-model-2.0/#base-context

> Implementations MUST treat the base context value [...] as already retrieved

@evan @finner https://www.w3.org/TR/activitypub/ says nothing about the `replies` collection, and even if it did, there is not currently a good way to follow a collection (or to do so recursively for such replies collections). The closest we have in-spec is inbox forwarding (which sadly doesn't get implemented by most fedi softwares!) but there's still the issue in maintaining a consistent and complete audience for who should get which notifications (and how to add or remove yourself to such audiences).