Octothorpes: Hashtags for the Open Internet | Hacker News Reader

Octothorpes: Hashtags for the Open Internet

octothorp.es

81 pointstodsacerdoti40 comments

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.

Web discoverability still seems like a challenge. Lots of echo chamber algorithms feeding to engagement/rage. Whats the next step?

I'd love to hear more about your experience with web discoverability, as I'm making a product that aims to help with that. Email me at alec.stanford.larson @ gmail

I don't know if much can be done about echo chambers. People seem to like their echo chambers. For those who are sick of such environments, I've designed another system (not yet part of the product I mentioned above) that I believe has the potential to breed a place of authenticity on the internet.

Wow. Status and age in a single comment. Loved del.icio.us

What a throw back

This defined, in many ways, how link associations on the web were/are percieved

Loved del.ico.us, thanks!

I'm using https://pinboard.in/ now for bookmarking and it's an amazing piece of small web software.

Small note: pinboard owns delicious since 2017!

Oh well. I also could not find bookmark manager that suit my needs. So I have built it.

https://github.com/rumca-js/Django-link-archive

I wanted something self host able, with easy export/import, with simple search ability, support for many crawling capabilities etc. etc.

Not del.icio.us (Thanks for all the fish!), but I experimented with bookmarklets [1] embedding JavaScript back in the 2000s as a way to create an independent bookmark system for browsers.

[1] https://en.wikipedia.org/wiki/Bookmarklet

yes. delicious was the multiuser rewrite of a previous system from 1999 or so. first archive save is 2002 but i was already writing delicious at that point. https://web.archive.org/web/20020525043925/http://muxway.org...

More details. https://web.archive.org/web/20030326132356/http://about.reve...

We very much would not be working on this if not for your 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.

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 more real world users.

When my collaborator saw this he said "isn't our whole point 2003 had some good ideas that we want to revisit with perspective from today.”

Also -- Memepool was an early fav of mine and an inspiration for https://mothra.click/, which I built in 45 minutes 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 non-zero impact on the existence of Octothorpes.

Yep. Delicious came from muxway, which itself was built to help with running Memepool…

Oh interesting. Were you thinking of the "subjects" on Memepool as tags already?

Not really. Memepool way predated that (1998?)

Was there a clear point where TAGS emerged as a distinct concept to you or was it a more gradual movement from the "subject" days? I read Maciej's account of ingesting A03s giant tag ecosystem in which he quotes you calling tags "a reverse search engine." That stuck with me as an insight that doesn't come up as much in a world where we take tags for granted. Curious how you got from Memepool to there.

It came from the text file I used to organize links ( the predecessor to muxway, itself the predecessor to del.icio.us)

Was your db a text file?

Oh, on the reversible webpage it's written that categories are by users so it's like wiki - At first I thought that it's done by any user and not pages authors. But now I'm interpreting it as just authors, just like in Octothorpes.

Well, Hi. I'm one of the guys working on Octothorpes -- thanks all for digging into our project! So, some context. You've found the project in a sort of liminal stage between launched and not launched. 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 https://weirdweboctober.website/ asked if they could use it, and they very much are. See https://octothorp.es/~/weirdweboctober. 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.

I've compiled a bunch of answers to this and a discussion on Lobste.rs in a blog post > https://ideastore.dev/blog/shrodingers-launch/ but will address some specific questions about the protocol in-line here.

    <link rel="octo:octothorpes" href="architecture">

Wait, no. While this wouldn't cause much issue due to the unrecognized link type, `href` should always be a valid URL and can't be a free-form string. This is more obvious when you realize that `rel` accepts multiple link types:

    <link rel="octo:octothorpes help" href="architecture">

A conformant agent will recognize `help` and treat this like `<link rel="help" href="architecture">`. The same goes for `<a rel="octo:octothorpes" ...>`. The correct way would be using standard-recognized elements and attributes instead:

    <meta name="octo:octothorpes" content="architecture">
    <a href="/blabla" itemscope>
        <meta name="octo:octothorpes" content="architecture">
        blablablabla
    </a>

rel is also broken. It should probably use a dash instead of a colon, unless octo: is intended to be a new uri scheme.

In this context `rel` will be an unordered set of unique space-separated tokens [1], which have no restrictions other than not including any ASCII whitespace.

[1] https://html.spec.whatwg.org/multipage/common-microsyntaxes....

If you only ever support HTML, but not the wider web linking syntax / IANA Link Relationships registry that might be fine, but I don't think it's ideal for a new protocol.

octo: is an RDFa prefix, and, as comments mention below, is a valid string for a rel value.

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">.

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 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.

A late fix: the second `<meta name="octo:octothorpes" content="architecture">` should use `itemprop` instead of `name`. I thought I have made that edit before...

There’s a link on that page that says you can check out some open source code.

https://github.com/stucco-software/octothorp.es

But this link gives a 404.

Probably the repo is currently private. Maybe they forgot to make it public?

Correct. We just made it public.

> Backlinks are links that go … back. Pages within a Ring can see which other pages linked to them.

I'm reading up on web history. I believe this was one of Ted Nelson's criticisms of the web (and reasons why Xanadu was supposedly better), right?

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.

at the time, it was folklore that lack of backlinks was the key "worse is better" inferiority/superiority which meant Sir (as he is now) Tim's web became —unlike all the sundry previous attempts at hypertext— world wide.

Lagniappe: https://github.com/floren/ching/blob/2d36a6ca0dd89f5a2e317d8...

Good critical overview. My impression is that Ted Nelson came at hyperlinks from a purer information scientists POV, whereas Sir Tim and CERN team were more pragmatic network engineers. They probably didn't anticipate the spam problem but likely did see that asking another host to store state on your behalf wasn't optimal.

You don't need a single autonomous domain, you just need a web of trust where other hosts are allowed to send trackbacks/webmentions to your site once they prove free from abuse. That's essentially how the Fediverse works - bad servers can simply be banned from the network. (And the Fediverse shares a lot more than simple backlinks, so the risk of abuse is correspondingly higher.)

Obviously that comes with a lot of caveats: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Re...

The page mentions "rings" but only links to register on the one on the same domain. Are other rings just "theoretically possible if someone hosts the app" or are they already here?

We have a demo of multi-server usage here https://demo.ideastore.dev/multi-server and here https://octothorpedwordpress.com/how-it-works/ and are actively working with people interested in hosting their own ring.

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.

Reply on news.ycombinator.com