Thursday, 2022-07-07

A simple update queue for HN&&LO

HN&&LO is chugging along fine, almost three years after release.

One thing that’s bothered me for a while is that I don’t keep the score and comments for Hackernews entries up to date in a timely manner. So far, I’ve been going back and re-reading last month’s entries but this means that the daily view generally isn’t up-to-date.

The HN API is hosted on Firebase and thus has the ability to get real-time data, but there’s no Perl interface to it, and I really don’t have time to tinker with an entire async setup for a page that’s updated every hour at most.

Instead I’ve implemented a simple queue to keep items up to date.

Every time I read new entries from HN, I add them to the queue. I set a time about an hour in the future.

Every ten minutes or so, I check for items that are older than the current time. If there are items, I compare the data stored in my database to the current status in HN. If there’s a change, I update my datastore and re-submit the item into the queue about 2 hours in the future.

If an item is unchanged, I re-submit it 2 times in case it gets some attention.

If an item is “low score” (currently max 2 upvotes and no comments) it’s given on more chance before being removed from the queue entirely.

I’ve been working on a crude visualization of the queue, it can be seen here:

I log items that are added to the DB here:

Hopefully this will make the main page a bit more informative than before, although just as.

Friday, 2022-07-01

Microblog blatherings, June

Get ‘em half-fresh here:

Tuesday, 2022-06-07

Microblog blatherings, May

It’s where the action is.

Like and subscribe, as the saying goes.

Tuesday, 2022-05-31

Thursday, 2022-05-19, one year later

One year ago, the failed businessman and accused felon Andrew Lee burned the Freenode network to the ground in a fit of childish pique. Luckily, responsible people were hip to his inept shenanigans and managed to launch a new network - - under his very nose.

In the intervening year, Freenode is a shadow of its former self. Even the alt-right lowlifes who gleefully became mods to settle old scores have slunk away to their slimy holes, and what’s left is an empty tomb, briefly visited by confused chatters who haven’t gotten the memo.

About 2 months after the events, I wrote the following little essay which never got polished enough for publication. I figured I could just dump it here now.

Slava Libera!

Irc culture wars (2020-07-20)

IRC as a mainstream cultural phenomenon peaked in 2002. At around that time, Freenode was started to address the issues with IRC as it was: spam, warez, channel and nick hijacking, and a general juvenile attitude.

Freenode saw a need for FOSS projects to have stability. To be able to claim and keep the channels they wanted, to be able to address spam and trolls, and to have a stable environment to point users to.

At the time, Freenode was the fussy nerd, not participating in the chaos the cool kids reveled in. But it filled the need for FOSS projects, and found its own niche within IRC.

As time passed, people left IRC, but many FOSS projects stayed on Freenode. This meant that as time passed, Freenode become more and more dominant within IRC. And the IRC culture that Freenode fostered became the norm, instead of the exception.

As IRC shrank, those that held the old IRC ideals dear were forced to use Freenode more and more. There they came into conflict with the Freenode norms. Conflicts about channel ownership and the wider issues of “free speech” erupted and were dealt with. Coupled with the entryism strategy of the alt-right and the general undercurrent of right-libertarianism of FOSS, this created a minority of dissidents on Freenode, at least as well versed in IRC warfare as the staff.

The takeover/coup of Freenode should be seen in this context. The dominant ideology of new Freenode is free speech, anti-LGBT, and adherence to fringe Unix shibboleths such as anti-systemd, anti-Codes of Conduct, and anti anti-RMS. And they would have gotten away with it too, had not the old staff adroitly moved to, and convinced almost every FOSS project to move too. Those that didn’t move were soon alienated by the new staff, who were more interested in settling old scores than the boring work of IRC stewardship.

Andrew Lee and his hardcore supporters are now betting that there’s still a market for old-style IRC, while at the same time loudly proclaiming their continued allegiance to FOSS. But their victory is hollow. They have won the battle but probably lost the war.

Monday, 2022-05-16

PSA: unmaintained project channels on Freenode automatically redirect to #freenode

During the management changes at Freenode in Jul 2021, all access lists and channel ownerships were reset. Existing channels that were not reclaimed by projects now automatically redirect to the main channel, which is #freenode.

If you have a specific question about a project, please make sure you’re actually in a maintained channel, and not in the main channel.

If the channel is not maintained, try checking the project’s homepage for their IRC presence. It’s usually under the “Community” section.

Saturday, 2022-04-30

Gemini in April

Link to portal.

Thursday, 2022-03-31



Mar 2021 | Mar 2020 | Mar 2019 | Mar 2018 | Mar 2017 | Mar 2016 | Mar 2015 | Mar 2014 | Mar 2013 | Mar 2012 | Mar 2011 | Mar 2010 | Mar 2009

Gemini in March

I’m really enjoying using my gemlog to vent.

Link to portal.

Saturday, 2022-03-12

18,000 dead in Sweden

DateDeaths DaysDeaths/day
2020-03-11 1 0 0.0
2020-04-09 1 000 29 34.4
2020-04-19 2 000 10 100.0
2020-05-02 3 000 13 76.9
2020-05-18 4 000 16 62.5
2020-06-11 5 000 24 41.7
2020-11-01 6 000 143 7.0
2020-11-27 7 000 26 38.5
2020-12-12 8 000 15 66.7
2020-12-23 9 000 11 90.9
2021-01-02 10 000 10 100.0
2021-01-14 11 000 12 83.3
2021-01-27 12 000 13 76.9
2021-03-01 13 000 33 30.3
2021-04-24 14 000 54 18.5
2021-10-27 15 000 186 5.4
2022-01-26 16 000 91 11.0
2022-02-15 17 000 20 50.0
2022-03-12 18 000 25 40.0

Wednesday, 2022-03-02

Gemini in February

Some more action as I struggle with some server update issues. Other internal Gemini guffing is overshadowed by world events.

Link to portal.

Monday, 2022-02-28


St Eriksplan

Feb 2021 | Feb 2020 | Feb 2019 | Feb 2018 | Feb 2017 | Feb 2016 | Feb 2015 | Feb 2014 | Feb 2013 | Feb 2012 | Feb 2011

Tuesday, 2022-02-15

Gemini: TLS and its discontents

(originally posted to 🚀 my gemlog) gemini://

The TLS requirement of Gemini never really grabbed me. Solderpunk laid out the reason in this gopher post:

Encryption schemes like TLS aim to provide three things: authentication, integrety, and (transmission) confidentiality. Gemini fails to provide two of them.

The problems with TLS on Gemini can be summarized as follows:

External dependencies on a 3rd party library

This makes server development fragile, and complicates it to little gain.

Harder for older hardware to use gemini

On the one hand - super simple protocol that’s easy to parse!

On the other - you need to be able to handle the latest crypto.

TOFU stinks - authentication and integrity

To avoid the complexities of PKI (via Certificate Authorities), Gemini is ok with TOFU (Trust On First Use), which basically means the client will more or less blindly accept whatever cert comes down the pipe. This can crucially be a man-in-the-middle cert. This means that potentially nothing on a gemsite can be trusted to not be manipulated by the MiTM, including any metadata about the certificate.

Not that this really matters, because most clients don’t show any metadata anyway.

To fully trust a server cert under TOFU, the user must

  • be able to view the metadata
  • be able to compare that to a known source - which is impossible to provide on the gemsite itself. The “best” solution is a HTTPS site known to be under the control of the gemsite operator.

In addition, many gemsite operators (re-)use certs meant for HTTPS, often provided via Let’s Encrypt (see below). These certs have a short validity, so if you visit many gemsites, be prepared to see the popup about the cert being changed many times. Is it due to cert rollover or a hostile MiTM? Who knows?

The same goes for stuff like PGP keys, and potentially politically sensitive speech, which was a big selling point in Solderpunk’s original proposal to add encryption to Gopher.

An entry into the pro-column: encrypted transit (confidentiality)

So what’s left? ISPs etc. cannot directly read Gemini traffic. But they can see that Alice’s IP has visited Bob’s IP, using a port other than 443. If gemini ever becomes big, the use of gemini on port 1965 itself is a decent fingerprint. Expect ads appearing in your browsing advertising gemini-adjacent products, like ortholinear keyboards and off-grid cabin living.

Great DANE to the rescue?

DANE does seem to be a nice end-run around the need for CA certs. But they are much harder to set up compared to generating a self-signed cert.

An aside: “Let’s Encrypt!” - but why?!

Let’s Encrypt is an impressive project. They’ve managed to streamline the issuence of TLS certs for websites, they’re running a “real” CA, and they’re doing it at no cost to the user. Behind LE is EFF and other boosters of the 90s Net vision of pervasive encryption. If everyone encrypts traffic, it doesn’t stand out as much, and we are all safer (for some libertarian values of safer). And of course, mainstream browsers are slowly ratcheting up the pressure by showing scary warning triangles for plain http:// sites.

I resisted getting a CA cert for my website for a long time because I only serve read-only content. The main selling point for such sites from LE was

  • authentication - the website is identified through the cert
  • integrity - the contents of the website cannot be altered in transit.

Confidentiality sounds cool but if you’re not serving sensitive data it’s not that big a deal.

Gemini is largely read-only and specifically designed to be that way. The fact that TOFU negates authentication and integrity makes it even more ironic that it was saddled with TLS.

A missed opportunity?

In retrospect, it would have been nice for Gemini to be usable without TLS, and TLS to either use CA certs or DANE (ideally DANE, to kickstart that a bit). But right now, we’re stuck with it.

I don’t see it as a reason not to use Gemini, but I will continue to point out the inherent uselessness of it going forward.


Björn (ew0k) has already written about this, I suggest reading the following which are coming from someone who knows their stuff: