🔁 https://twitter.com/dret/status/655067542721945600
Amy shared https://twitter.com/dret/status/655067542721945600
uris (3 out of 3)
Blog post content types
Finally you can get my blog post content in a number of different formats. You'll notice alternative URLs (noted currently as 'Permalink') in the metadata section of a normal view of a post. Hit this up with no Accept header, and you'll get neat markdown (which is what I authored it in; the 'source', as it were).
Browsers automatically send Accept: text/html, in which case they are redirected to the rendered HTML version of the post you're probably reading now. But here are some alternatives you can try:
curl https://rhiaro.co.uk/llog/micropub-test-> plain markdown.
curl -H "Accept: application/json" https://rhiaro.co.uk/llog/micropub-testbecause there's obviously not enough JSON in the world. Note this isn't correct JSON-LD yet. I'll sort that out another time.
curl -H "Accept: text/turtle" https://rhiaro.co.uk/llog/micropub-testOhemgee! RDF! It's what you've all been waiting for, I know.
For those of you who like angular brackets, you could try:
curl -H "Accept: rdf/xml" https://rhiaro.co.uk/llog/micropub-testRelevance to micropub
Briefly discussed with Tantek, Aaron and Bret at IWC Cambridge and on IRC about how a micropub client could fetch post content for editing. Many people aren't editing raw HTML as it's presented on the page, but maybe markdown or some other syntax, so a client needs to be able to discover this (the 'source') to present it to be edited. Now if someone makes their client check a post for a rel="source" or shoots off a request with Accept: text/plain (less likely, since static sites can't do conneg) then they'll get my markdown directly (uh, when I actually put rel="source" in my HTML, which I haven't yet).
As a related aside, I also return source="markdown" if a micropub client asks my endpoint q=source.
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: