@xuu@txt.sour.is Oh geez! Is this anywhere near you?

@falsifian@www.falsifian.org Thank you! 🙏

If we want this though (or some of us do) I will probably have to make the hard decision here to just fork from Twtxt entirely and define a completely new spec. If we care about the UX we need a few properties (some of which we have, some of which we don’t have and some of which are “weak”):

• Authenticity
  
• Integrity
  
• Precision Versioning
  

The last one involves actually supporting the notion of “Edits” and “Deletes” IMO more formally. Without this it would be quite hard to support a strong/good UX. Another way to think about this is “Versioned Twts”.

I think the only legit way of preventing this kind of “spoofing attack” would be:

Digitally Sign Twts: Each Twt could be digitally signed using a private key associated with the UUID. The signature would be calculated over the concatenation of the UUID, timestamp, and content. The public key could be published along with the feed so anyone can verify the authenticity of the Twt by checking the signature. This approach ensures that only the true owner of the UUID (and the corresponding private key) can produce valid hashes.

Which leads us to more Cryptography. Something which y’all voted against.

@bender@twtxt.net This is sadly where you need two things:

• A /twtxt.txt.sig (detached signauture)
  
• Or a way to sign the # uuid = with a key that can be verified.
  

Hmmm and as I write this actually, I think this doesn’t work either, because you can still just copy it regardless. Hmmm @xuu@txt.sour.is help me out here? How do we prevent “spoofing”? 🤔

That page says “For the best experience your client should also support some of the Twtxt Extensions…” but it is clear you don’t need to. I would like it to stay that way, and publishing a big long spec and calling it “twtxt v2” feels like a departure from that. (I think the content of the document is valuable; I’m just carping about how it’s being presented.)

It’s for this reason I’d like to try changing the Twt Hash extension to use SHA-256 which is a far more common tool available pretty much everywhere. I think the effort involved in “precise threading” (using content addressing) becomes much easier to “author” (note that participating in an existing thread has always been trivial, just copy the Twt Subject in your Twt).

Again, I like this existing simplicity. (I would even argue you don’t need the metadata.)

I argue you do. It’s nice to have a “@nick@domain` a feed author prefers to be called by, rather than you just making shit™ up haha 😝

It’s also quite nice to have a visual representation of the feed too. description can be optional.

Without this, feeds are a bit too “bland” IMO.`

@falsifian@www.falsifian.org Yeah I agree with this actually (introducing too many changes at once is often a bad idead):

but IMO that shouldn’t be done at the same time as introducing new untested ideas

@bender@twtxt.net Bahahahahahahaha 🤣

This is why we need “authenticity” 🤣 Yes if you copied my feed’s UUID, then you’d end up generating identical hashes to me if we posted at identical times with identical timestamps. Not good 😌

Also, was the dot after the timestamp intended?

No, sorry.

For example a v2 spec might just simply mandate the following as a starting point:

cat <<EOF
# nick = $USER
# avatar = https://example.com/$USER.png
# description = Hi 👋 I'm Bob!
# uuid = 7E9BC039-4969-4296-9920-4BACDBA8ED5C

2024-09-28T11:19:25+10:00   Hello World!
EOF > ~/public_html/twtxt.txt

And:

• Serve your file with Content-type: text/plain; charset=utf-8

@falsifian@www.falsifian.org I don’t have a problem with continuing the way we have been for the past ~4 years, little extensions and improvements that we try along the way. That has worked quite well 💪 As a blind person myself, I can totally empathise with reading a full (lots of text) spec. Even if we decide to combine all the ideas into a full fleshed out v2 spec, it might be worthwhile having a cut-down version that is as simple as it can be a no less.

Deprecating non-UTC times seems reasonable to me, though.) Having a big long “twtxt v2” document seems less inviting to people looking for something simple. (@prologic@twtxt.net you mentioned an anonymous comment “you’ve ruined twtxt” and while I don’t completely agree with that commenter’s sentiment, I would feel like twtxt had lost something if it moved away from having a super-simple core

See https://yarn.social (especially this section: https://yarn.social/#self-host) – It really doesn’t get much simpler than this 🤣

@falsifian@www.falsifian.org We’ve been doing this for years:

There are lots of great ideas here! Is there a benefit to putting them all into one document? Seems to me this could more easily be a bunch of separate efforts that can progress at their own pace:

See https://dev.twtxt.net

@bender@twtxt.net I’m not following it, but someone on my pod is 🤣 And yes based on statistical evidence, I doubt you’ll see a reply either 🤣

@doesnm@doesnm.p.psf.lt The useragent tool now natively supports the Caddy (JSON) logfile format. 🥳

This is a 1-way feed by the looks 🤣 Maybe someone can figure out how to reach out to this person and see if they’re aware and interested in something a bit more “social” (albeit slow) 🤣

@falsifian@www.falsifian.org Sorry I didn’t make that super clear 🤦‍♂️ Be happy to see you there and some new folks 🙇‍♂️

This Facebook/Meta story on storing passwords in plain text it just wow 😮 – Like how da fuq does a company, or anyone for that matter in the business of software / technology even do this?! Like at least base64 encode the fuckers right?! (oh wait 🤦‍♂️)

@xuu@txt.sour.is If you have time, could you help me pinpoint this bug? 🐛

@lyse@lyse.isobeef.org It’s from 12pm to 4pm UTC so if you can make it at all, that’d be great 👍

@xuu@txt.sour.is Do you think we should just detect edits at the client-level then? 🤔

Probably the best idea I’ve heard/seen si far is @anth@a.9srv.net’s idea of a feed having a uuid # uuid = (if present) otherwise just falling back to the URL you fetched it from and dropping the idea of a feed # url = entirely.

@lyse@lyse.isobeef.org Yup you’re right, it’s s terrible idea 💡

Well the poll clearly shows:

• ~65/35 in favor of Content Addressing
  
• ~60/40 in favor of supporting Edit/Delete
  
• ~70/30 against more cryptograph
  

And an NPS score of 7/10 🤣

@bender@twtxt.net Zero technical issues 🤣 I never claims otherwise 😅

@bender@twtxt.net Yes but you’ve got me curious now 😅

Okay, co-founder of Wordpress and CEO of Automation.

What has the poor guy done? 🤣

@david@collantes.us Who’s Matt Mullenweg? 🤔

Like really tbh, it’s just a matter of abstracting out the “fetching” part of your client. There are zero issues with fetching Gopher/Gemini hosted feeds. They just lack any mechanisms for Discovery and Caching.

@doesnm@doesnm.p.psf.lt Still haven’t received it. Did you send to james at mills dot io? 🤔

@movq@www.uninformativ.de I don’t think I intend to either tbh for yarnd. If there was any poorly worded “things”, it was just merely pointing out lacking capabilities for caching and discovery.

@bender@twtxt.net Oh so what you’re saying is “we” (royal we) ruined Twtxt 🤣

@doesnm@doesnm.p.psf.lt Are you sure? Not seen the mail yet…

@aelaraji@aelaraji.com LOL 😂 Here’s one for you:

You can take IRC out of my cold 🥶 dead 😵 hands 🙌

Anyway I’ve setup an alias now 🤣

@doesnm@doesnm.p.psf.lt Ooops you might want to re-send that to james instead 🤣

@aelaraji@aelaraji.com It sadly does not it seems. 🤣 Seems like the search engine has come across mentions of your feed via its other two protocols 🤣

$ inspect-db yarns.db | jq -r '.Value.URL' | grep 'aelaraji.com'
https://aelaraji.com/test_feed.txt
https://aelaraji.com/twtxt.txt

@doesnm@doesnm.p.psf.lt My Salty public key is:

kex1fhxntuc0av7q48hlfj970ve297dzzghn82wp5cahr9r92y8rlrqqtwp983

@doesnm@doesnm.p.psf.lt Do you have a sample Caddy log file you can supply? I’ll see if we can improve the tool 👌

@doesnm@doesnm.p.psf.lt Fot a sample access log? Which tool are you using?

@doesnm@doesnm.p.psf.lt I don’t think it does. I think it’s completely different to what you’re thinking.

@doesnm@doesnm.p.psf.lt Yeah just move your feet. It’s totally fine. Don’t worry about it.

@doesnm@doesnm.p.psf.lt I couldn’t find any references to this anywhere either.

@doesnm@doesnm.p.psf.lt Like now?

@doesnm@doesnm.p.psf.lt I have no idea to be honest 🤣 I’m actually not really sure how you can ruin something be improving it 🤦‍♂️

We:

• Drop # url= from the spec.
  
• We don’t adopt # uuid = – Something @anth@a.9srv.net also mentioned (see below)
  

We instead use the @nick@domain to identify your feed in the first place and use that as the identify when calculating Twt hashes <id> + <timestamp> + <content>. Now in an ideal world I also agree, use WebFinger for this and expect that for the most part you’ll be doing a WebFinger lookup of @user@domain to fetch someone’s feed in the first place.

The only problem with WebFinger is should this be mandated or a recommendation?

Something @anth@a.9srv.net said on ITC

17:42 I should also note in there that it doesn’t address the two things i really want it to: mandate utf-8 (which should be easy to fit in) and something for better @ mentions.

I actually agree with in both counts and it got me thinking…

you’ve ruined twtxt

Not sure what to say here. 🤔

Thank you for all the hard work put into the project.

Thank you to whomever said this! 🙇‍♂️

Many of the faces go hand in hand or depend on the selected protocol a feed is published with or client features. I’m pretty sure people interpret different things into these terms.

See previous. Sorry 😞

Not sure what to think about the stack ranking question. I care that it’s a simple text file i can just stick on my server. Security, identity, &c come out of how I manage the server.

See previous.

I don’t know what all the facets mean. E.g. what’s the difference between “Integrity” and “Authenticity”?

Yes, I totally get where you’re coming from. However after ~22 results, I think y’all have figured out how to rank them appropriately anyway 🤣

Sharing the comments of the poll (anonymous so I have no idea whom the comments are from):

your poll should include questions about markdown. personally i think inline bits like style, links, images are yes. block quotes, code blocks, bullet lists are mid. but tables and footnotes are no.

Yes sorry about this, I wasn’t able to change much after publishing the poll 😅

@slashdot@feeds.twtxt.net GTFO 🤣

cc @xuu@txt.sour.is

@bender@twtxt.net Well as you’ve pointed out in the past, both protocol suffer from Discovery (as I’ve stated as well) and more often than not, users that publish Twtxt feeds over these protocols tend to just “point into the void” and it’s next to impossible to have any kind of “social interaction” (ignoring personal choices of course, if one’s feed is intended for 1-way …)

I think there’s a bug in yarnd hwoever:

$ yarnc debug https://sunshinegardens.org/~xjix/twtxt/tw.txt
...
bqor23a 2024-09-26T11:09:28-07:00	if twtxt 2 is dropping gemini support, i will probably move on and spend more time on my gemini social zine protocol instead. i think the direction of the protocol is probably fine, but for me web is a tier 2 publishing channel. if the choice is between gemini and http i'm always going to pick gemini. its been a fun ride, but i guess this is where i get off.

The yarnc CLI tool and the lextwt parser we use in yarnd correctly parses the feed and sets the Twter.HashingURI to the latest # url = found in the feed. However my pod hasn’t picked this up 😢 I follow @cuaxolotl@sunshinegardens.org as https://sunshinegardens.org/~xjix/twtxt/tw.txt

Gemini/Gopher Twtxt feeds account for less than 1% in existence:

$ total=$(inspect-db yarns.db | jq -r '.Value.URL' | awk -F'//' '{if ($1 ~ /^https?/) print "http/https:"; else print $1}' | sort | uniq -c | awk '{sum+=$1} END {print sum}'); inspect-db yarns.db | jq -r '.Value.URL' | awk -F'//' '{if ($1 ~ /^https?/) print "http/https:"; else print $1}' | sort | uniq -c | awk -v total="$total" '{printf "%d %s %.2f%%\n", $1, $2, ($1/total)*100}' | sort -r
7 gemini: 0.66%
4 gopher: 0.38%
1046 http/https: 98.96%

Note however this doesn’t solve the problem of Caching at all. It just works around it and with enough clients fetching a Gopher/Gemini feed, this # refresh becomes useless anyway at a certain point of scale.

@bender@twtxt.net Well this is the thing really. Gopher and Gemini are very broken ways to distributed content. Broken in the sense that for Twtxt either support a) caching in any way shape or form b) discovery in any way shape or form.

This is a bit of a problem because if a Feed author complains (nad they have in the past) that their Gopher/Gemini feeds are being hit “too hard”, well that’s really kind of on them for choosing to host their feed on an ill advised protocol thatc cannot possibly support Caching at all.

This is primarily one of the reasons we introduced the idea of a “feed advised refresh interval” that clients SHOULD respect.

See: https://dev.twtxt.net/doc/metadataextension.html#refresh

refresh
This optional field is used by feed authors as a hint to clients to control how often they should fetch or update this feed.

The value of this field is seconds represented by an integer.

NOTE: An empty, bad, or unparsable value is ignored.

@bender@twtxt.net To be fair, this has never been a problem for folks that have/use stable Feed URI(s) 🤣

This is confirmed to be the case:

$ for url in gemini://sunshinegardens.org/~xjix/twtxt/tw.txt https://sunshinegardens.org/~xjix/twtxt/tw.txt //sunshinegardens.org/~xjix/twtxt/tw.txt; do yarnc hash -t '2024-09-26T11:09:28-07:00' -u "$url" "if twtxt 2 is dropping gemini support, i will probably move on and spend more time on my gemini social zine protocol instead. i think the direction of the protocol is probably fine, but for me web is a tier 2 publishing channel. if the choice is between gemini and http i'm always going to pick gemini. its been a fun ride, but i guess this is where i get off."; done
fk2af7q
7kvnpaq
bqor23a

Yup confirmed!

# url = //sunshinegardens.org/~xjix/twtxt/tw.txt
# url = https://sunshinegardens.org/~xjix/twtxt/tw.txt
# url = gemini://sunshinegardens.org/~xjix/twtxt/tw.txt

@cuaxolotl@sunshinegardens.org has changed the url of their feed (yet again) and changed every hash in their feed.

@antonio@twtxt.net is right to call this out. We should drop the reliance on the # url metadata field and in fact we should probably just drop this entirely from the spec and go with # uuid as the basis of a feed’s identity.

Even though this happens very rarely (feeds moving to new locations) it more frequently happens with folks that try to serve their feed from Gopher, HTTP and Gemini.

@bender@twtxt.net Hmm I think I know why…

2024-09-27T01:28:53Z	(#bqor23a) @<cuaxolotl https://sunshinegardens.org/~xj9/twtxt/tw.txt> Wait, what!? We're dropping Gemini support!?

From @aelaraji@aelaraji.com’s feed. I think @cuaxolotl@sunshinegardens.org doesn’t do threading properly, I’ve run into this once before. I’m not sure what client they use? 🤔

@bender@twtxt.net Hmm I think I know why…

2024-09-27T01:28:53+00:00	(#bqor23a) @<cuaxolotl https://sunshinegardens.org/~xj9/twtxt/tw.txt> Wait, what!? We're dropping Gemini support!?

From @aelaraji@aelaraji.com’s feed. I think @cuaxolotl@sunshinegardens.org doesn’t do threading properly, I’ve run into this once before. I’m not sure what client they use? 🤔

Search engine doesn’t know about it either: https://search.twtxt.net/twt/bqor23a

@bender@twtxt.net Re that broken thread (#bqor23a). Its the same one. My pod doesn’t have the Root Twt: https://twtxt.net/twt/bqor23a => 404 Not Found.

How in the hell did you even reply to this in the first place?

Hmmm https://twtxt.net/twt/bqor23a => 404 Not Found 🤣

@bender@twtxt.net What was this in reply to? 🤔

@aelaraji@aelaraji.com Probably not.

@cuaxolotl@sunshinegardens.org Context?

(#bqor23a) @aelaraji@aelaraji.com
@cuaxolotl@sunshinegardens.org We probably won’t in fairness. i only called it out because discovery is made much harder with Gopher and Gemini. Caching is also impossible too.

@cuaxolotl@sunshinegardens.org We probably won’t in fairness. I only called it out because discovery is made much harder with Gopher and Gemini. Caching is also impossible too.

Last chance to have your say before tomorrow’s meetup:

http://polljunkie.com/poll/xdgjib/twtxt-v2

No reason I haven’t switched. I trust Gitea (for now).

@david@collantes.us SQLite

@david@collantes.us Yup! 🤞

@david@collantes.us Staying private until I’ve matured them a bit more 😅

“For every complex problem, there is a solution that is clear, simple, and wrong.”

– H.L. Mencken

Also, I’m not editing the original post. 😅

@bender@twtxt.net ha ha yes ideally one day I would love it if Twt hashes referenced at least any yarnd clients were automatically linked. 🤣

“Everything should be made as simple as possible, but not simpler.”
– Albert Einstein

The beauty of simplicity lies in not losing the essence.

#simplicity #Einstein #wisdom

Don’t forget about the upcoming Yarn.social monthly online meetup. See #jjbnvgq for details.

Last day to have your say before our monthly online meetup 👋

http://polljunkie.com/poll/xdgjib/twtxt-v2

@anth@a.9srv.net Thank you I’ll have a read 👌

@sorenpeter@darch.dk i’m just saying that your argument, better support better clients and worrying less about the actual underlying raw Twtxt feed. so the simplicity argument is a bit weaker here.

@sorenpeter@darch.dk This is an argument for better clients really and less worry about the “transport” – the raw Twtxt feed file.

@sorenpeter@darch.dk CPU cost of calculating hashes are negligible

@lyse@lyse.isobeef.org Haha 😝

@lyse@lyse.isobeef.org Now increase the indexes on the Twt Subject form 7 bytes to 64 bytes 😈

@lyse@lyse.isobeef.org Congrats 🙌

Hmm this question has a leading “Yes” in favor of so far with 13 votes:

Should we formally support edit and deletion requests?

Thanks y’all for voting (it’s all anonymous so I have no idea who’s voted for what!)

If you haven’t already had your say, please do so here: http://polljunkie.com/poll/xdgjib/twtxt-v2 – This is my feeble attempt at trying to ascertain the voice of the greater community with ideas of a Twtxt v2 specification (which I’m hoping will just be an improved specification of what we largely have already built to date with some small but important improvements 🤞)

Starting a couple of new projects (geez where do I find the time?!):

HomeTunnel:

HomeTunnel is a self-hosted solution that combines secure tunneling, proxying, and automation to create your own private cloud. Utilizing Wireguard for VPN, Caddy for reverse proxying, and Traefik for service routing, HomeTunnel allows you to securely expose your home network services (such as Gitea, Poste.io, etc.) to the Internet. With seamless automation and on-demand TLS, HomeTunnel gives you the power to manage your own cloud-like environment with the control and privacy of self-hosting.

CraneOps:

craneops is an open-source operator framework, written in Go, that allows self-hosters to automate the deployment and management of infrastructure and applications. Inspired by Kubernetes operators, CraneOps uses declarative YAML Custom Resource Definitions (CRDs) to manage Docker Swarm deployments on Proxmox VE clusters.

I think that’s one of the worst aspects of the proposed idea of location-based addressing or identity. The fact that Alice reads Twt A and Bob reads Twt A at the same location, but Alice and Bob could have in fact read very different content entirely. It is no longer possible to have consistency in a decentralised way that works properly.

One could argue this is fine, because we’re so small and nothing matters, but it’s a properly I rely on fairly heavily in yarnd, a properly that if lost would have significant impact on how yarnd works I think. 🤔

Unless I”m missing something here 🤔 But a <url> <timestamp> does not for me identify an individual Twt, it only identifies its location, which may or may not have changed since I last saw a version of it hmmm 🧐

Also I’m not even sure I can validly cache, let alone index feeds anymore if we do this, because if the structure of a Twt is cuh that I can no longer trust that an individual Twt’s content hasn’t been changed at the source, what’s the point of caching or indexing individual twts at all? This makes the implementations of yarnd and yarns (the search engine, crawlers and indexer) kind of hard to reason about.

Also you’re right I guess. But still that also requires the author not to change the timestamp too. Hmmm

@movq@www.uninformativ.de I don’t think there’s any misunderstand at all. I just treat every lines in a feed as an individual entity. These are stored on their own.

@movq@www.uninformativ.de So I obviously happen to agree with you as well. However in so saying, one of my goals was also to bring the simplicity of Twtxt to the Web and for the general “lay person” (of sorts). So I eventually found myself building yarnd. Has it been successful, well sort of, somewhat (but that doesn’t matter, I like that it’s small and niche anyway).

I agree that the goal of simplicity is a good goal to strive for, which is why I’m actually suggesting we change the Twt identifiers to be a simple SHA256 hash, something that everyone understand and has readily available tools for. I really don’t think we should be doing any of this by hand to be honest. But part of the beauty of Twt Subject and Twt Hash(es) in the first place is replying by hand is much much easier because you only have a short 7 or 11 character thing to copy/paste in your reply. Switching to something like <url> <timestamp> with a space in it is going to become a lot harder to copy/paste, because you can’t “double click” (or is it triple click for some?) to copy/paste to your clipboard/buffer now 🤣

Anyway I digress… On the whole edit thing, I’m actually find if we don’t support it at all and don’t build a protocol around that. I have zero issues with dropping that as an idea. Why? Because I actually think that clients should be auto-detecting edits anyway. They already can, I’ve PoC’d this myself, I think it can be done. I haven’t (yet), and one of the reasons I’ve not spent much effort in it is it isn’t something that comes up frequently anyway.

Who cares if a thread breaks every now ‘n again anyway?

@doesnm@doesnm.p.psf.lt Like maybe you need to check something, debug a client, or whatever 😅