This is an interesting (pronounced like "frustrating") thread.
-
Nik | Klampfradler πΈπ²replied to nilesh last edited by
Content being identified by IRIs (not URLs) is the backbone of the web. It could probably be other kinds of IRIs, yes, but don't drop the IRIs. And make sure they always stay dereferencable through HTTPS.
-
nileshreplied to Nik | Klampfradler πΈπ² last edited by
@nik @jenniferplusplus What's this IRI you speak of?
-
Nik | Klampfradler πΈπ²replied to nilesh last edited by
Basically, what you refer to as a URL (which, for the current state of the Fediverse, mostly is the same because virtually all IRIs of ActivityPub contents are URLs today).
But actually, ActivityPub content has an IRI, which does not have to be a URL, not even today: https://en.wikipedia.org/wiki/Internationalized_Resource_Identifier
-
nileshreplied to Nik | Klampfradler πΈπ² last edited by
@nik @jenniferplusplus IRI seems to be about just allowing extra characters, not content-addressing.
It would be easy enough to build content-addressability within existing URLs. For example:
`https://myblog.com/my-article-<multihash>.html`
Web browsers could have built this universally for all resources when defining the SubResource Integrity spec which is ensures that JS scripts a page downloads has not been tampered with. They chose `<script integrity="<hashalgorith>-<hashvalue>">` instead.
-
Nik | Klampfradler πΈπ²replied to nilesh last edited by [email protected]
The difference is the third letter β I vs. L.
An IRI (or URI), in contrast to a UR**L**, does **not** need to be a concrete HTTP address on the public web that can directly be loaded from a web server.