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

Gaining kernel code execution on an MTE-enabled Pixel 8
In this post, I’ll look at CVE-2023-6241, a vulnerability in the Arm Mali GPU that allows a malicious app to gain arbitrary kernel code execution and root on an Android phone. I’ll show how this vulnerability can be exploited even when Memory Tagging Extension (MTE), a powerful mitigation, is enabled on the device.

The post [Gaining kernel code execution on an MTE-enabled Pixel 8](https://github.blog/2024-03-18-gaining-kerne … ⌘ Read more

@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!

<darch> or is it #tags that messe up the hash?

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.

yarnd v0.13 - Aluminium Amarok
Today we announced release v0.13.0 of the Yarn.social backend yarnd that now powers a network of 15 pods around the globe.

You can find the release here:

• https://git.mills.io/yarnsocial/yarn/releases/tag/0.13.0
  

Yarn/Twtxt (Yarn.social is based on Twtxt) continues to grow steadily every day, and every month or so we see a new independent Pod (what we call in … ⌘ Read more

@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.net why do I see https://twtxt.net/search?tag=d5sj7ba as twtxt source in your tweets? This is not a text file…

@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 Wow! Really interesting perspective! Thanks for sharing. :-)

@prologic@twtxt.net I see Consul service mesh everywhere these days, X-D thanks to a 180 career change and major upskill.

@prologic@twtxt.net Really helpful context: was definitely over-engineering. Cheers!

@prologic@twtxt.net The favicon in particular! :-)

@prologic@twtxt.net lol. quitfacebook.org is still up. twt is set to be on more radars, though. ;-)

@prologic@twtxt.net Yeah, a completely-unsolicited surprise! :-) And, sweet! To IRC then!

@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 Txtnish adds a 28 character timestamp to the message, so in Bash: tweet=tail -1 the current twtxt.txt file and then pipe echo body=${tweet:28} to twt.

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

i just realized i have no idea how to tag/mention someone else on this thing. i tried but i don’t think it worked?

@prologic@twtxt.net (#https://twtxt.net/search?tag=tsvhqdq OK. Im upgrading my tools. twtxt works pretty well inside an Emacs shell window…

and then ignore it “notmuch search not tag:unsubscribe and date:yesterday..”

tag anything with the word “unsubscribe” by “notmuch tag +unsubscribe unsubscribe”

in the original twtxt your URL is your identity. No need for anyone outside your control to do account managment. One reason I’ll likely be sticking with command line. But, great work

FWIW, I put up a quick blog last night about using twtxt command line https://eludom.github.io/blog/hello_twtxt/

What flavor or regexp? I tried here https://regexr.com/ with both PCRE and JavaScript and neither seems quite right. I’m relatively good with regexps, but they tend to be write-only :-/

yes. I read that. Nice post. Brave browser at least has trouble with formatting. The regexp got lost when renederd. Eww (emacs text browser) doees just fine with it :-)

@prologic@twtxt.net what is the exact syntax neeed for threads to work in the subject, e.g. will (#tsvhqdq) do it? The whole … (#tsvhqdq) thing seems like a bit of overkill. Too many characters.

as the person who motivated CompuServe’s USENET gateway https://www.chicagotribune.com/news/ct-xpm-1994-10-07-9410070309-story.html I’ve see what happens when the unwashed masses are turned loose in techie playgrounds

One very real problem to be aware of is “Eternal September” https://en.wikipedia.org/wiki/Eternal_September