+ The History of the URL: Path, Fragment, Query, and Auth - Eager Blog
Amy added https://eager.io/blog/the-history-of-the-url-path-fragment-query-auth/ to https://rhiaro.co.uk/bookmarks/
uri (4 out of 4)
- Check the
targetis a valid URI on my site after following redirects. - try again with the correct URI,
- update their system with the correct URI, knowing I've accepted the webmention against the correct URI on my end (more like a (2NN)[http://tools.ietf.org/html/draft-prudhommeaux-http-status-2nn-00] than a 303).
Permalinks and webmention
As mentioned in Blog Post URIs, I'm a bit concerned about people replying to the 'wrong' URI for a post. That is, using the URL of a HTML page with the post rendered within it, rather than the post's permalink.
I couldn't find a Microformats2 term for permalink, which I thought would be the obvious solution.
The webmention 'protocol' says that when I recieve a webmention:
In my case, upon recieving a target of a https://rhiaro.co.uk/yyyy/mm/id, to validate it, rather than 'following a redirect' I'll actually be getting it's foaf:topic from the triplestore, which is fine. But in accepting this as the target I'm confirming to the sender that this is the correct URI to reply to. Hypothetically this non-permalink could break, breaking the reply. The permalink URI is one I'm promising won't break, so it's in everybody's interests to send the reply there. But logically, if somebody is linking to me in a post of their own, they're going to want to link to the rendered version, rather than whatever my raw version will look like (probably crappy, but that's on me, and maybe part of the problem).
Replying to shortlinks
Because I'm a linked data nut, my problem derives from a deliberate differentiation between a blog post and a page about a blog post. The connection between them (or from one to the other) can be discovered through RDF, but there is no HTTP redirection. I suspect this is a very much minority use-case for #indieweb folks.
However, use of shortlinks is widespread (and you can see redirects are accounted for in the webmention protocol), and so as soon as someone's URL shortner breaks (or moves) permanently, unless they store the post contents and metadata themselves, they might have to have to think about this a bit.
Solution?
I'd like to be able to send back the correct URI (303 redirect style) so the sender can either:
or
I haven't looked at any implementations yet or thought about how to do it, so maybe I can just do this. I'm not sure how to anticpate people handling it.
Straw poll: What do you/your system do if you send a webmention and it's rejected, though you're sure the target is valid?
And if you're going to send your reply as a webmention from your own system, please target this post's permalink - the URI without a year and a month in :)
Last modified:
Blog Post URIs
My instinct is telling me to separate a 'raw' blog post from a rendered version which includes html markup, css styles, replies from other people, a header, footer, maybe links to other pages on my website on a menu somewhere, ...etc. Because an instance of a blog post is not the same as the post mashed into an HTML page along with replies and other stuff. The replies can stand alone on the social web, so the original post should be able to.
So 'raw' post URIs are in the form https://rhiaro.co.uk/llog/unique-post-slug and the rendered versions are found at https://rhiaro.co.uk/yyyy/mm/unique-post-slug. The rendered versions have a slashy-datey URL because it makes it obvious that you can filter back to temporal aggregates by removing parts of the URL. It's just plumbing and a bit of UX++, which is partly why I don't want to use this format as the URI for the blog itself (I might change my plumbing one day).
Dereferencing the rendered URI obviously returns the rendered page in all its glory.
Dereferencing the 'raw' URI should still return a document, not redirect, because a blog post can be retrieved over HTTP. But what exactly should it return? A bunch of plain text turtle maybe; all the triples with the URI as the subject. Or minimally marked up HTML (including microformats, I suppose, and maybe RDFa). I guess I just have an arbitrary decision to make here.
So what's the relationship between the 'raw' URI and the rendered one? Maybe <raw> foaf:primaryTopicOf <rendered> and <rendered> foaf:primaryTopic <raw>? (Or maybe I should coin a new renderedAt property to make the relationship clearer).
But when people want to start sending replies from their own sites, they're automatically going to want to use the rendered URI as the subject of their in-reply-to, however they do it, which would be technically incorrect; they should be replying to the blog post itself, not this rendering of it. Or maybe this is a context in which it doesn't matter, and the 'raw' and the rendered are essentially sameAs each other.
Maybe I call the 'raw' a permalink, and make it clear on the rendered page, and hope people point their replies at the right place.
But if people do muddle the blog post and the (essentially) page-about-the-blog-post in their interactions with it, it probably doesn't matter; I can disambiguate them appropriately on my end. Maybe do some contextual reinterpretation experiments in the process (watch this space).
How do other people handle this? Well the people who are replying to each others' blog posts from their own sites are indieweb and they're not necessarily big on the linked data or pedantic arguments about what a URI 'means'. Todo: Find out if anyone has implemented a blog or similar with LDP.
Last modified:
URIs for content creators and content
Generating unique IDs
In a centralised system, I could generate my own unique IDs by whatever means, assign them, and be done with it.
I thought briefly about trying to generate human-readable unique IDs, but this article made me decide that that will all end in tears.
Maybe for now I assume that people won't need to remember their OnlinePersona URI... Dangerous? Maybe. Maybe not. Maybe it's more likely that someone will be searched for by all the properties of their OnlinePersona, but the OnlinePersona itself doesn't matter directly. We shall see.
So on that note, Python's UUID will do. They're long and horrible. But I'll get over it.
Power to the people
How do I persist creator and content URIs in a non-centralised, user-owned network?
People would need the option to change their URI to whatever they felt represented themselves, like their personal 'about me' page. Trying to enforce content negotiation and a Document != Person mentality here might be difficult.
Ultimately it doesn't really matter what their URI is as long as it resolves and persists, right? And if it doesn't resolve, or even disappears entirely, it's kind of rubbish, but not Web-breaking. Kind of the reason the Web still holds up, and the reason the Semantic Web is an extension of that.
Assuming a distributed, Diaspora*-esque 'Pod' structure for this network, if a user moves to another Pod and as a result must change their URI, the protocols involved essentially need to require leaving a 'forwarding address' to their new URI. Maybe, in this scenario, URIs are handled differently altogether. Separately from the Pods. You can get a URI from the Pod you just joined, or you can use your own or generate one from a provider.
How do you authenticate changing of a URI? Someone could essentially steal someone else's identity by switching out their URI... so... that can't happen.
Maybe I'm thinking too much. I might need to talk to someone smarter about this.
Last modified: