4 ms·

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 d

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. The whole thing is clearly half-baked, written by someone who doesn’t understand the meanings and reasons for things. I wouldn’t touch it, as it stands. Using a fetch preload to index, and identify what the actual ring is that’s being used, since you just use keywords later on and not full URLs… yuck. That’s legitimately dreadful. 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. 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">.

pikematchbox 2y ago
This part of the 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 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: 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. > 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. Term collision is very much something we've been thinking about. For now it has to be handled manually. But 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.

pikematchbox 2y ago

This part of the 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 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: 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. > 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. Term collision is very much something we've been thinking about. For now it has to be handled manually. But 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.