@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

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