Octothorpes is currently in a sort of liminal stage between launched and not launched, but it got posted to Lobsters and Hackernews today! Which was quite a surprise to both of us. So, if you’re reading this because you found out about us on one of those sites, here’s a little context for the project.
We only started telling people about it at XOXO, and planned a semi-public roll out for some time this month. But then Weird Web October asked if they could use it, we said yes, and they very much are, so we’re in a little holding pattern where we’re keeping it open for them but not promoting it to the wider world yet. “Post on Hackernews” is definitely not in this part of the roadmap, but we really appreciate that someone considered it worth sharing!
So caveats are that our documentation isn’t fully up to date, some features aren’t part of core yet, and we’re still in a fairly rapid test and update cycle. Definitely caught some things in need of updating today, so thanks all.
The demo site has working examples of most of what you can do with Octothorpes right now, and a quickstart guide if you’re interested in trying it out yourself.
We are still setting up proper communications for the roll out, but because of this we’ll set up a newsletter and mastodon presence in short order and this post will be the first post on the
The first planned stage of the roll out is codenamed Ratbike – we’re getting the barebones version of the protocol (and docs) up and running to ratbike standardards and will send out invites and offer support to a limited number of sites for a finite test period, probably a few months. If you’re interested in joining, sign up for the mailing list for the full announcement. (This will strictly be for technical news and not a marketing list.)
A lot of specific questions got asked, so here are some
It’s really cool to see people engaging with specifics of the protocol. Let’s see what they have to say:
Over on Lobste.rs singpolyma asks:
Why not use rel=tag which has been the standard for over a decade?
Why not use webmention or trackback or pingback instead of a brand new preload based indexing hack?
and coby gives a pretty good answer!
I guess the point of
rel=octo:octothorpeoverrel=tagis to decouple the hashtag itself from a canonical document?
Exactly!
But since each ring server has a document for that hashtag by definition, you could just do
rel="tag" href="<ring>/~/<tag>"and have the server parse the tag out of the URI. So fair point there. The authors seem to be big fans of RDF, so it’s a little strange they didn’t just use that standard.
Good question! Right now, when we use a custom value like octo:octothorpe, it’s a valid predicate that gets passed straight into the RDF. But… this tag idea. Dang, good point! The href="<ring>/~/<tag>" pattern is part of the protocol but not well-documented, but simplifying this to just the rel="tag" is reaaaaal nice. Thanks Coby, that’s probably going in the next update.
Nik elaborates more:
The main idea behind not defaulting to rel=tag is that using an RDF namespace makes a little simpler to convert HTML straight over to RDF as you need a namespace for RDFa. But something that’s on our immediate roadmap is the idea that we can express the same idea as this RDFa tag through other formats – rel=tag being one of them, alongside things like Microformats, or even just custom-defined HTML structures. We call these harmonizers, and they will work to make whatever code you use on your site to express tags understandable and interoperable with the Octothorpes server.
Webmentions, trackbacks, and pingbacks all require a proactive action from the linking site. With an Octothorpe ring you sacrifice some decentralization for the ability to index all the sites passively, with the only implementation required from each site being to write a bit of HTML (and the one-time step of getting your domain approved). This also means that each author need not control their own server, they only need to control the content.
Totally. Very well said, Coby. I will just reiterate that we are designing the system to be a constellation of servers, and are working to make running your own server (ring) as easy and cheap as possible, all towards more robust decentralization.
The preload-based indexing may be a hack, but it is an elegant one IMHO. It is what allows the indexing to be passive, lowering the bar for entry.
Thanks Coby! One-line, passive indexing is very important to us. And watching it happen with Weird Web October has been really exciting. It’s even working on CodePen. The preload also gives us a real HTTP origin request header to work with, which offers some url verification without any tracking.
Ok, moving on.
kaycebasques asks
It seems like webmention, trackback, and pingback only notify you of the backlinks once, when the article is published. Is that right? And I have to set up a server to receive those one-off notifications? Does Octothorpes work the same way?
Ideally I would be able to query backlinks to my site at any time and wouldn’t need a server to receive notifications. Can’t picture how that would work, though…
Backlinks, like any object in the Octothorpe ecosystem, do have an endpoint you can query at any time. So we’re not doing notifications as much as providing that endpoint. You can see it in action here: https://demo.ideastore.dev/backlinked-page
Backlinks currently need a little more love to get to parity with hashtags, so look for things like a web component and standard library for querying backlinks in future updates.
I built this in like 2003. https://web.archive.org/web/20030212162207/http://reversible…
It didn’t work, so I built del.icio.us instead.
Well, shit, Joshua Schachter has entered the chat. The same one I refer to in Why We Built Octothorpes.
We very much would not be working on this if not for his earlier work. However, despite writing a grant proposal in which I had to research the history of backlinks and attempts at implementing them, I had not known about Reversible. And it’s super cool to find out about.
When Nik saw this he said:
isn’t our whole point is “2003 had some good ideas that we want to revisit with perspective from today”
So I get why Joshua would say this, but I’ll point out that he built Reversible for an interenet that hadn’t yet fully benefited from other projects by Joshua Schachter, so one without a robust concept of tags, let alone hashtags. A lot of the questions on the Further questions, problems, observations list for Reversible are front and center for us, and we’re hoping to demonstrate some answers to them as we roll things out to real world users.
Bonus – Memepool, another Schachter joint, was an early fav of mine and an inspiration for https://mothra.click/, which I built for my wife, who has never owned a smartphone, so I could send her links. Getting lazy about updating it meant “Wanting to post to mothra.click easier” had a nonzero impact on the existence of Octothorpes, and I’m planning a rebuild to make it 100% Octothorpe powered.
Ok, on to the haters constructive feedback.
This looks interesting but I was disappointed to see that registration requires polluting the root domain with a TXT record. Would be nice if this could be at a subdomain like _octothorpe-verify or something like that.
We agree! That’s why we don’t require this anymore. That was an early approach that we need to remove from the docs. We’re currently building out a web-of-trust approach too, but authentication / verification in general is something we want to test in the real world and learn from before a fully public release.
Even in <a rel="octo:octothorpes" href="/architecture">, when it says that href “references a Tag on an Octothorpes Ring as well as a URL on your website”, it doesn’t say _how_ it worked out that it’s #architecture.
And here’s where I realize our documentation needs serious cleaning up – which is one of the reasons we haven’t done a public launch yet. This is referring to: https://octothorp.es/docs#anchor-tag which is a bit of an edge case that we may not even launch with. This example anticipates a circumstance where someone would want to link to their own url, such as their own tag page, and at the same time use that term as an octothorpe. This might be something no one wants! TBH I’m not sure if it’s even implemented anywhere right now. It certainly shouldn’t be more prominent in the docs than the basic anchor-based implementation that got discussed over at Lobste.rs.
Now it’d be fine to use href if only they had the full URL: <link rel="octo:octothorpes" href="[https://octothorp.es/~/architecture](https://octothorp.es/~/architecture)">.
Totally agree. This hits on what we’re actually going to ship for how to create in-line octothorpes with plain anchor tags, and the docs should reflect the primacy of this approach.
To review, we’re currently implementing three methods of octothorping a url:
<link> tag in the <head>
direct link to the ring’s term you want to use.
via the <octo-thorpe> web component
The suggestions on Lobste.rs are almost certainly going to get implemented and make this all simpler, too.
Suppose you want to be on _two_ rings, and they use the same keyword, but differently—what do you do? “You can only be on one ring” is a rather unnecessary and limiting restriction.
Also agree, which is why that is not a restriction. We have two live demos of thorping to multiple rings from the same URL. See https://demo.ideastore.dev/multi-server and https://octothorpedwordpress.com/how-it-works/. Super glad someone asked about this – made me realize the first link wasn’t using the current protocol, which is now updated.
Term collision is very much something we’ve been thinking about. For now it has to be handled manually. Because we’re building the whole system off of an RDF base, we have a lot of low-level tools to define and process different vocabularies in some powerful ways. The same term having different meanings on different servers is the most immediate application of this, and it’s high on our roadmap.
Backlinks only work within a benevolent autonomous domain. In a federated system, it is quickly discovered how to flood them with spam. which is why, rightfully so in my opinion, the web does not even try to have automated backlinks. That is, you can only link to something, you can’t link from something, you can’t put a link on somebody else’s site pointing to your own.
The closest it has is the referer header. And if you feel lucky you can build your backlink system out of that.
This and the ensuing discussion gets at concerns we share. Our approach so far is to 1. Build for distributed networks (ie multiple rings) and 2. require endorsement from the target of a backlink. An unendorsed backlink is just… a link. We’re still building out tools to moderate / filter requests for all statements (not just backlinks) from the network, but want to offer a wide scope of filters, from whole rings down to domains, subdomains, and arbitrary strings. Also Web of Trust! Currently under dev for registering domains and other permissions, such as backlink endorsement.
There’s also some discussion of the use of meta vs link elements in the document head, and our use of rev. We’ve gone back and forth on this, and right now <link> makes sense for current and future features, but we’re open to suggestions. As far as using rev vs rel, rev may be obsolete but it was built for backlinks. We’re partly using it to connect to the history of attepmted implementatons. In strict RDF usage, rel has pros and cons, and does fit in the sense that it only makes a statement about a URL. There’s no reason we can’t or won’t support backlinking using rel but it’s a broader space where other schemas make statements, so ours would be one of many. At this moment, rev being depreciated frees the space for us to use it as an implicit statement within the octo: vocabulary.
Otherwise, some cool discussion about backlinks and discoverability, so, you know, love to see that.
Ok, phew, that’s enough for today. Thanks all for reading talking about our quasi-launched project.