🥳 Just released Gatherly v0.3.0 🤟 – My instance is available at: https://gatherly.mills.io (free for anyone to use)

Pretty happy with my zs-blog-template starter kit for creating and maintaining your own blog using zs 👌 Demo of what the starter kit looks like here – Basic features include:

• Clean layout & typography
  
• Chroma code highlighting (aligned to your site palette)
  
• Accessible copy-code button
  
• “On this page” collapsible TOC
  
• RSS, sitemap, robots
  
• Archives, tags, tag cloud
  
• Draft support (hidden from lists/feeds)
  
• Open Graph (OG) & Twitter card meta (default image + per-post overrides)
  
• Ready-to-use 404 page
  

As well as custom routes (redirects, rewrites, etc) to support canonical URLs or redirecting old URLs as well as new zs external command capability itself that now lets you do things like:

$ zs newpost

to help kick-start the creation of a new post with all the right “stuff”™ ready to go and then pop open your $EEDITOR 🤞

#awesome #zs

@bender@twtxt.net Yup! Fixing that now! 👌 Also the Tags page and the size of the trags is intentional, as more posts are tagged with the same tag, those will result in larger size rendered tags in a kind of “tag cloud” – At this this is the intention.

@prologic@twtxt.net need to work on the CSS. For example, the tags are too big, the code blocks (and the inline ones) are too small, the single posts have no date (intended?), and so on. It’s an alpha start!

I just created a zs blogging template which I’m going to use for https://prologic.blog and I might starting writing long-form again soon™ 🔜 So far the “blogging” template/engine (if you weill) is quite simple. It comprises essentially of an index.md a prehook and a few utilities:

$ git ls-files
.gitignore
.zs/config.yml
.zs/editthispage
.zs/include
.zs/layout.html
.zs/list
.zs/months
.zs/now
.zs/onthispage
.zs/posthook
.zs/postsbymonth
.zs/prehook
.zs/scripts
.zs/styles
.zs/tagcloud
.zs/taglist
.zs/years
archives/.empty
assets/css/site.css
assets/js/main.js
index.md
posts/hello-zs-blog.md
posts/on-tagging.md
posts/second-post.md
tags/.empty

TNO Threading (draft):
Each origin feed numbers new threads (tno:N). Replies carry both (tno:N) and (ofeed:<origin-url>). Thread identity = (ofeed, tno).

• Roots: (tno:N) (implicit ofeed=self).
  
• Replies: (tno:N) (ofeed:<url>).
  
• Clients: increment tno locally for new threads, copy tags on reply.
  
• Subjects optional, not required.
  

…

@kat@yarn.girlonthemoon.xyz hey, hey, good afternoon, happy Friday! Fandom site tag pages count. Word!

The image needs to be an absolute URL, and some tags are missing. Almost there!

We finally got a caliper donated for this year’s scout flea market. We didn’t sell it, but kept it ourselves. It will come in very handy every now and then in our material store. For example, I missed having a caliper in the past when sorting our random assortment of screws or measuring the depth of a hole. It’s a wee bit banged up (probably happened during transport) and didn’t come with a box, but the latter is now solved.

The lid and bottom came from a wardrobe back panel I got from a mate, the sides were rocket sticks in their former lives. I found some scrap of felt in our material store and some hinges laying around in the drawers of my own workshop.

Unfortunately, the table saw teared up the plywood veneer fibres badly, even though I put tape around to prevent that. This is the first time it didn’t work. At. All. To cover that up, I painted the box with some decades old tinting paint (price tag says Deutsche Mark, not Euro!) from my paint cabinet. It’s awesome, works absolutely perfectly and doesn’t smell the slightest bit. I reckon, this caliper box is plenty good enough for occasional use at our scout material store.

On my blog: Free Culture Book Club — Tag Team https://john.colagioia.net/blog/2025/06/14/tag-team.html #freeculture #bookclub

@abucci@anthony.buc.ci two things. Conduwuit, a Matrix server written in Rust, is no longer going to be developed. The other is, I didn’t mean to tag you, but because Yarnd was broken it happened. Apologies.

Hmmm there’s a bug somewhere in the way I’m ingesting archived feeds 🤔

sqlite> select * from twts where content like 'The web is such garbage these days%';
      hash = 37sjhla
  feed_url = https://twtxt.net/user/prologic/twtxt.txt/1
   content = The web is such garbage these days 😔 Or is it the garbage search engines? 🤔
   created = 2024-11-14T01:53:46Z
created_dt = 2024-11-14 01:53:46
   subject = #37sjhla
  mentions = []
      tags = []
     links = []
sqlite>

Doesn’t look like it Hmmm

sqlite> select * from twts where content LIKE '%Linux installation%';
    hash = znf6csa
feed_url = https://www.uninformativ.de/twtxt.txt
 content = I wonder if my current Linux installation will actually make it to 20 years:

    $ head -n 1 /var/log/pacman.log
    [2011-07-07 11:19] installed filesystem (2011.04-1)

It’s not toooo far into the future.

It would be crazy … 20 years without reinstalling once … phew. 🥴
 created = 2025-04-07T19:59:51Z
 subject = (#znf6csa)
mentions = []
    tags = []
   links = []

@prologic@twtxt.net In all seriousness: Don’t worry, I’m not going to host some Fediverse thingy at the moment, probably never will. 😅

But I do use it quite a lot. Although, I don’t really use it as a social network (as in: following people). I follow some tags like #retrocomputing, which fills my timeline with interesting content. If there was a traditional web forum or mailing list or even a usenet group that covered this topic, I’d use that instead. But that’s all (mostly) dead by now. ☹️

For point 1 and others using the metadata tags. we have implemented them in yarnd as [lang=en][meta=data]

oh dang.. i thought i had parsing for !tag from back when someone was using it for his wiki pages.
i guess i left it out. though shouldnt be to hard to add it back in

@falsifian@www.falsifian.org
it look like your markdown image tags are missing the protocol part (https://) so they don’t render at least on my server: https://darch.dk/timeline/conv/3vtnszq

Now I just have to remember to tag people in replays ✍

hmm interesting work here.. ill give it a look.. @lyse@lyse.isobeef.org do you know if it is even storing the url into the AST object? afair the code to parse tags url should be the same as the mention url.

What was it suppose to look like? a <detail><summary>-tag maybe?

More:

Subject: The [tag URI scheme](https://en.wikipedia.org/wiki/Tag_URI_scheme) looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be
        somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick? Instead of using `tag:` as the prefix/protocol, it would more it clear
        what we are talking about by using `in-reply-to:` (https://indieweb.org/in-reply-to) or `replyto:` similar to `mailto:` 1. `(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)' 2.
        `(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)' 2. `(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)' I know it's longer that 7-11 characters, but it's self-explaining when looking at the
        twtxt.txt in the raw, and the cases above can all be caught with this regex: `\([\w-]*reply[\w-]*\:` Is this something that would work?

Subject: The [tag URI scheme](https://en.wikipedia.org/wiki/Tag_URI_scheme) looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be
        somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick? Instead of using `tag:` as the prefix/protocol, it would more it clear
        what we are talking about by using `in-reply-to:` (https://indieweb.org/in-reply-to) or `replyto:` similar to `mailto:` 1. `(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)` 2.
        `(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)` 3. `(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)` I know it's longer that 7-11 characters, but it's self-explaining when looking at the
        twtxt.txt in the raw, and the cases above can all be caught with this regex: `\([\w-]*reply[\w-]*\:` Is this something that would work?

Notice the difference? Soren edited, and broke everything.

The tag URI scheme looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be somewhat trivial to parse. But there are still the issue with what the name/id should be… Maybe it doesn’t have to bee that stick?

Instead of using tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:

1. (reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)
   
2. (in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
   
3. (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
   

I know it’s longer that 7-11 characters, but it’s self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex: \([\w-]*reply[\w-]*\:

Is this something that would work?

@mckinley@twtxt.net

HTTPS is supposed to do [verification] anyway.

TLS provides verification that nobody is tampering with or snooping on your connection to a server. It doesn’t, for example, verify that a file downloaded from server A is from the same entity as the one from server B.

I was confused by this response for a while, but now I think I understand what you’re getting at. You are pointing out that with signed feeds, I can verify the authenticity of a feed without accessing the original server, whereas with HTTPS I can’t verify a feed unless I download it myself from the origin server. Is that right?

I.e. if the HTTPS origin server is online and I don’t mind taking the time and bandwidth to contact it, then perhaps signed feeds offer no advantage, but if the origin server might not be online, or I want to download a big archive of lots of feeds at once without contacting each server individually, then I need signed feeds.

feed locations [being] URLs gives some flexibility

It does give flexibility, but perhaps we should have made them URIs instead for even more flexibility. Then, you could use a tag URI, urn:uuid:*, or a regular old URL if you wanted to. The spec seems to indicate that the url tag should be a working URL that clients can use to find a copy of the feed, optionally at multiple locations. I’m not very familiar with IP{F,N}S but if it ensures you own an identifier forever and that identifier points to a current copy of your feed, it could be a great way to fix it on an individual basis without breaking any specs :)

I’m also not very familiar with IPFS or IPNS.

I haven’t been following the other twts about signatures carefully. I just hope whatever you smart people come up with will be backwards-compatible so it still works if I’m too lazy to change how I publish my feed :-)

@prologic@twtxt.net How does yarn.social’s API fix the problem of centralization? I still need to know whose API to use.

Say I see a twt beginning (#hash) and I want to look up the start of the thread. Is the idea that if that twt is hosted by a a yarn.social pod, it is likely to know the thread start, so I should query that particular pod for the hash? But what if no yarn.social pods are involved?

The community seems small enough that a registry server should be able to keep up, and I can have a couple of others as backups. Or I could crawl the list of feeds followed by whoever emitted the twt that prompted my query.

I have successfully used registry servers a little bit, e.g. to find a feed that mentioned a tag I was interested in. Was even thinking of making my own, if I get bored of my too many other projects :-)

@prologic@twtxt.net Sorry, my messages don’t get included in the current convo unless I tag you. Guess something gets lossed in translation with this weird posting issue. ANYWAY, it is rather perplexing. Clearly only an issue on my Pod, but what could the source of it be 🤔

Added support for #tag clouds and #search to timeline. Based on code from @dfaria.eu@dfaria.eu🙏

Image

@lyse@lyse.isobeef.org its a hierarchy key value format. I designed it for the network peering tools i use.. I can grant access to different parts of the tree to other users.. kinda like directory permissions. a basic example of the format is:

@namespace
# multi
# line
# comment
root :value

# example space comment
@namespace.name space-tag 

# attribute comments
attribute attr-tag  :value for attribute

# attribute with multiple 
# lines of values
foo :bar
      :bin
      :baz

repeated :value1
repeated :value2

each @ starts the definition of a namespace kinda like [name] in ini format. It can have comments that show up before. then each attribute is key :value and can have their own # comment lines.
Values can be multi line.. and also repeated..

the namespaces and values can also have little meta data tags added to them.

the service can define webhooks/mqtt topics to be notified when the configs are updated. That way it can deploy the changes out when they are updated.

What about using the blockquote format with > ?

Snippet from someone else’s post
by: @eapl.me@eapl.me

Would it not also make sense to have the repost be a reply to the original post using the (#twthash), and maybe using a tag like #repost so it eaier to filter them out?

Release jq 1.7rc1 · jqlang/jq · GitHub

Renewed activity on jq after five years. This RC looks nice!

An option would be to have /twtxt.txt be the base functionality as bukket intended without subject tags, markdown, images and such truncated to 140 chars. a /yarn.txt that has all the extentions as we know and love. and maybe a /.well-known/webfinger + (TBD endpoint) that adds on the crypto enhancements that further extend things.

The rise of tags on online articles saying how many minutes it takes to read them says, to me, a lot about our breakneck-speed culture.

@eldersnake@yarn.andrewjvpowell.com There isn’t an equivalent for those because:

Markdown is not a replacement for HTML, or even close to it. Its syntax is very small, corresponding only to a very small subset of HTML tags.

You can read more of its philosophy at Daring Fireball. There are enhancements to Markdown (CommonMark, for example), that add extra to it.

@adi@f.adi.onl Yes, it did—at least I don’t see the same issue as before on twtxt.net. Weird, as it was never an issue on other pods. 🤷🏻‍♂️

@prologic@twtxt.net should we enable all unicode glyphs for tags? https://txt.sour.is/conv/55yrura

Image

Image

@prologic@twtxt.netYes, I think tags should just be #foo, and let the client figure out searching if it cares.

@lyse@lyse.isobeef.org Yes, I often read the raw messages. But more to the point, the simplicity of the format is the bulk of the appeal.

@movq@www.uninformativ.de No argument that threading is an improvement. But I think (#hash) does that, and I think figuring out how to search should mostly be up to the client.

I don’t have any issue with the (foo) subjects, it’s the proliferation of the (foo url) tags. They’re just too long and ugly.

@prologic@twtxt.net I’ve just never had it be a rewarding experience.

@prologic@twtxt.net rc, the Plan 9 shell.

@prologic@twtxt.net yep. it actually extracts everything at parse time. like mentions/tags/links/media. so they can be accessed and manipulated without additional parsing. it can then be output as MarkDown

@prologic@twtxt.net as promised! https://github.com/JonLundy/twtxt/blob/xuu/integrate-lextwt/types/lextwt/lextwt_test.go#

the lexer is nearing completion.. the tough part left is rooting out all the formatting code.

@oevl@twtxt.net @prologic@twtxt.net (#) for the most part a subject is just the content in the perens. Usually it’s a tag. It appears near the start after any mentions. It can also contain text like (re: subjects)

@prologic@twtxt.net (#keh22ka) maybe a custom linking method on a pod level? like can pass a template that gets translated. ex https://{domain}/wiki/{nick}/{tag} + !somepage -> https://sour.is/wiki/xuu/somepage

@prologic@twtxt.net do you have any info on how the ‘!’ tags are supposed to work? are they just a different kind of hash tag?

@prologic@twtxt.net I have some ideas to improve on twtxt. figure I can contribute some. 😁 bit more work and it will almost be a drop in replacement for ParseFile

Kinda wish types.Twt was an interface. it’s sooo close.

@xuu@txt.sour.is Not too happy with WKD’s use of CNAME over SRV for discovery of openpgpkey.. That breaks using SNI pretty quick. I suppose it was setup as a temporary workaround anyhow in the RFC..