@bender@twtxt.net You’d be surprised how many lifetime old accounts I still have, scattered all over the internet. I just don’t have much energy to go through deleting each and every single one of them. xD and here is a bonus image for LOLs

Image

OpenAI, Google, Anthropic admit they can’t scale up their chatbots any further

Once you’ve trained your large language model on the entire written output of humanity, where do you go?

https://pivot-to-ai.com/2024/11/14/openai-google-anthropic-admit-they-cant-scale-up-their-chatbots-any-further/

So we’re going to destroy the environment for AI slop that isn’t fit for purpose now and, if you believe the above post, never will be.

Easy run: 3.13 miles, 00:09:51 average pace, 00:30:54 duration
nice chill run. first day where my resting heart rate was back down to low 50s. no idea what was going on because i did not feel sick but maybe it was just all the stress from life and a crazy october?
#running

@eapl.me@eapl.me Neat.

So for twt metadata the lextwt parser currently supports values in the form [key=value]

https://git.mills.io/yarnsocial/go-lextwt/src/branch/main/parser_test.go#L692-L698

@eapl.me@eapl.me here are my replies (somewhat similar to Lyse’s and James’)

1. Metadata in twts: Key=value is too complicated for non-hackers and hard to write by hand. So if there is a need then we should just use #NSFS or the alt-text file in markdown image syntax ![NSFW](url.to/image.jpg) if something is NSFW

2. IDs besides datetime. When you edit a twt then you should preserve the datetime if location-based addressing should have any advantages over content-based addressing. If you change the timestamp the its a new post. Just like any other blog cms.

3. Caching, Yes all good ideas, but that is more a task for the clients not the serving of the twtxt.txt files.

4. Discovery: User-agent for discovery can become better. I’m working on a wrapper script in PHP, so you don’t need to go to Apaches log-files to see who fetches your feed. But for other Gemini and gopher you need to relay on something else. That could be using my webmentions for twtxt suggestion, or simply defining an email metadata field for letting a person know you follow their feed. Interesting read about why WebMetions might be a bad idea. Twtxt being much simple that a full featured IndieWeb sites, then a lot of the concerns does not apply here. But that’s the issue with any open inbox. This is hard to solve without some form of (centralized or community) spam moderation.

5. Support more protocols besides http/s. Yes why not, if we can make clients that merge or diffident between the same feed server by multiples URLs

6. Languages: If the need is big then make a separate feed. I don’t mind seeing stuff in other langues as it is low. You got translating tool if you need to know whats going on. And again when there is a need for easier switching between posting to several feeds, then it’s about building clients with a UI that makes it easy. No something that should takes up space in the format/protocol.

7. Emojis: I’m not sure what this is about. Do you want to use emojis as avatar in CLI clients or it just about rendering emojis?

Righto, @eapl.me@eapl.me, ta for the writeup. Here we go. :-)

Metadata on individual twts are too much for me. I do like the simplicity of the current spec. But I understand where you’re coming from.

Numbering twts in a feed is basically the attempt of generating message IDs. It’s an interesting idea, but I reckon it is not even needed. I’d simply use location based addressing (feed URL + ‘#’ + timestamp) instead of content addressing. If one really wanted to, one could hash the feed URL and timestamp, but the raw form would actually improve disoverability and would not even require a richer client. But the majority of twtxt users in the last poll wanted to stick with content addressing.

yarnd actually sends If-Modified-Since request headers. Not only can I observe heaps of 304 responses for yarnds in my access log, but in Cache.FetchFeeds(…) we can actually see If-Modified-Since being deployed when the feed has been retrieved with a Last-Modified response header before: https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/cache.go#L1278

Turns out etags with If-None-Match are only supported when yarnd serves avatars (https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/handlers.go#L158) and media uploads (https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/media_handlers.go#L71). However, it ignores possible etags when fetching feeds.

I don’t understand how the discovery URLs should work to replace the User-Agent header in HTTP(S) requests. Do you mind to elaborate?

Different protocols are basically just a client thing.

I reckon it’s best to just avoid mixing several languages in one feed in the first place. Personally, I find it okay to occasionally write messages in other languages, but if that happens on a more regularly basis, I’d definitely create a different feed for other languages.

Isn’t the emoji thing “just” a client feature? So, feed do not even have to state any emojis. As a user I’d configure my client to use a certain symbol for feed ABC. Currently, I can do a similar thing in tt where I assign colors to feeds. On the other hand, what if a user wants to control what symbol should be displayed, similar to the feed’s nick? Hmm. But still, my terminal font doesn’t even render most of emojis. So, Unicode boxes everywhere. This makes me think it should actually be a only client feature.

i do kinda like htmx, but i might end up going my own way with my own similar library that matches better with my use patterns which are really not compatible with any extra scripting. so less flexible, but possible more powerful in the end.

After testing Vivaldi for a couple of weeks I am convinced this is a great browser and to support the team behind it, I decided to start sending them a couple of Euro monthly, just to keep the momentum going.

@movq@www.uninformativ.de Ta! Absolutely, go for it. :-)

I’m seeing strange lights in the sky. None of my cameras are sensitive enough to make a video.

It’s probably one of two things:

1. A ship on the nearby river with a lightshow going. It’s rare but it happens.
   
2. A steap hill nearby, cars driving “upwards”, and since super bright LED lights are normal nowadays, they reflect from the clouds.
   

Either way, looks fancy.

@movq@www.uninformativ.de i’ve wondered the same thing.. dansup can be pretty erratic and i don’t really trust the guy. thankfully (at least from my perspective) he’s not the only game in town. though i think going UI-first is kind of jumping the gun. the fediverse doesn’t really have the infrastructure in place to support video publishing at the scale that a tiktok user might expect. based on some of dansups statements regarding palestine, i’m sure its partially an effort to control what kind of content makes it into fedi’s tiktok streams for the first while.

@prologic@twtxt.net yeah short Nick is going to be unique enough. There is always olong Nick that adds the domain for differentiation.

After the behaviour of a clearly very angry feed author over the past few days, I’m very tempted to give up on Twtxt and allow it to go back to being dead. What really is the point of building and supporting a way to exchange little pieces of text with one another in a completely decentralised way, if you’re just going to keep humping up against such hostility? I don’t know why I do this anymore.

After the behaviour of a clearly very angry feed author over the past few days, I’m very tempted to give up on Twtxt and allow it to go back to being dead. What really is the point of building and supporting a way to exchange little pieces of text with one another in a completely decentralized way, if you’re just going to keep bumping up against such hostility? I don’t know why I do this anymore.

mon niveau serait de 13-kyu, je ne sais pas si c’est bien :/ https://play.baduk.org/go-test/start.php?

@movq@www.uninformativ.de Although my recent breakage/down time was more of a result of human error than it is something to blame on software itself, I do get your point; and will highly probably end up going the same route in the near future. It’s just that in order to south my forever itching curiosity, I have to learn and try some things first.

@doesnm@doesnm.p.psf.lt Much appreciated!! 🙏 I’ll go through the files and see if I can understand any of it. I might learn a thing or two along the way.

Web interface is deleted in https://git.mills.io/saltyim/saltyim/commit/376de2702319686c902ec03b8ca1e17b020fc639 but seems incorrectly (in source i see git lfs metadata). Can be builded if you grab https://git.mills.io/saltyim/saltyim/src/commit/15a64de82829/internal/web/app.wasm and place it in source (go directory has cached source) and rebuild

There is a pressing need to hold Israel accountable, not only for its longstanding violations of international law, but specifically for its longstanding refusal to abide by its Charter obligations. In the face of this recalcitrance, the UN must move towards expelling Israel from the organization, not only because the UN exists to uphold international law, but also to maintain the UN’s integrity as an organization. The persistent, open violations by Israel of binding UNSC resolutions cannot go unpunished. The current situation, where Israel openly accuses the UN of bias, refuses to cooperate with the organization on multitude levels, defies binding orders of the ICJ, physically attacks UN premises and staff, and even moves towards designating a UN agency as a terrorist organization, is a clear threat to the authority of the UN – an issue which the UNSC raised explicitly in the case of South Africa. To allow the situation to continue would show that international legal norms, and rules of the UN binding member states, are applied on the basis of double standards: specifically, that states allied to powerful Western countries are afforded impunity. https://opiniojuris.org/2024/10/09/israel-must-be-expelled-from-the-united-nations/

Honestly… not much. Have abandon two projects (both private) on Golang and one related to cryptography. My mostly languages are Python and Javascript (also can PHP). After writing code on Go i spend same time on fixing dumb errors

@3r1c@3r1c.net I think I’m gonna like that blog. 😅 https://unixdigest.com/articles/is-the-madness-ever-going-to-end.html

Grand Canyon Rim To Rim: 27.90 miles, 00:28:36 average pace, 13:17:46 duration
grand canyon rim-to-rim with kelly and craig. it was a blast! a lot of firsts: crazy elevation, head lamps, poles. i had a really good time and then we started to encounter some elevation. definitely could feel the altitude as soon as there was an incline. then after so many large steps up my quads started to feel it. at one point everything seized up and i fell down. luckily craig jumped in my leg and started stretching it out which helped a lot. the rest of it from there it was slow going but only once the large steps were sparse we cruised ahead. definitely would do it again.
#running #race

i don’t normally reach for go when starting a project, but this pubsub gemini thing seems like a great addition to ~solderpunk/molly-brown and i was already intended on adding titan support so i might as well get familiar with the codebase.

Same! Great joke!

i like this one

I share I did write up an algorithm for it at some point I think it is lost in a git comment someplace. I’ll put together a pseudo/go code this week.

Super simple:

Making a reply:

1. If yarn has one use that. (Maybe do collision check?)
   
2. Make hash of twt raw no truncation.
   
3. Check local cache for shortest without collision
   
   • in SQL: select len(subject) where head_full_hash like subject || '%'
     

Threading:

1. Get full hash of head twt
   
2. Search for twts
   
   • in SQL: head_full_hash like subject || '%' and created_on > head_timestamp
     

The assumption being replies will be for the most recent head. If replying to an older one it will use a longer hash.

@prologic@twtxt.net I wanted to wait for things to settle down. It’s still unclear to me in which direction we’re going – and if that new/different stuff is even possible to implement in jenny. That said, I’ve been really busy with private stuff these last few days, I’ve lost track of most of what you’re discussing. 🥴

If we stuck with Blake2b for Twt Hash(es); what do we think we need to reasonably go to in bit length/size?

=> https://gist.mills.io/prologic/194993e7db04498fa0e8d00a528f7be6

e.g: (turns out @xuu@txt.sour.is is right about Blak2b being easy/simple too!):

$ printf "%s\t%s\t%s" "https://example.com/twtxt.txt" "2024-09-29T13:30:00Z" "Hello World!" | b2sum -l 32 -t | awk '{ print $1 }'
7b8b79dd

Apparently Drama is tech entities’ new Going Viral PR stunt. After the Wordpress vs. WPE mayhem, Godot starts it’s own, Who/what’s next?

@prologic@twtxt.net Regarding the new way of generating twt-hashes, to me it makes more sense to use tabs as separator instead of spaces, since the you can just copy/past a line directly from a twtxt-file that already go a tab between timestamp and message. But tabs might be hard to “type” when you are in a terminal, since it will activate autocomplete…🤔

Another thing, it seems that you sugget we only use the domain in the hash-creation and not the full path to the twtxt.txt

$ echo -e "https://example.com 2024-09-29T13:30:00Z Hello World!" | sha256sum - | awk '{ print $1 }' | base64 | head -c 12

There we go!

=> twtxt.dev

🥳

@bender@twtxt.net HAHA I’ve just bookmarked that Repo to go through it tomorrow 👌

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.

@anth@a.9srv.net you wrote:

“Edits and Deletions should go; see also Section 6. This is probably the worst example of this document pushing a text document to do more protocol-like things.”

Edit and deletions are precisely what brought us here. Currently, if one replies to a twtxt, and the original gets later edited, it breaks replies, and potentially drastically changes context.

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.

And finally the legibility of feeds when viewing them in their raw form are worsened as you go from a Twt Subject of (#abcdefg12345) to something like (https://twtxt.net/user/prologic/twtxt.txt 2024-09-22T07:51:16Z).

There is also a ~5x increase cost in memory utilization for any implementations or implementors that use or wish to use in-memory storage (yarnd does for example) and equally a 5x increase in on-disk storage as well. This is based on the Twt Hash going from a 13 bytes (content-addressing) to 63 bytes (on average for location-based addressing). There is roughly a ~20-150% increase in the size of individual feeds as well that needs to be taken into consideration (on the average case).

So really your argument is just that switching to a location-based addressing “just makes sense”. Why? Without concrete pros/cons of each approach this isn’t really a strong argument I’m afraid. In fact I probably need to just sit down and detail the properties of both approaches and the pros/cons of both.

I also don’t really buy the argument of simplicity either personally, because I don’t technically see it much more difficult to take a echo -e "<url>\t<timestamp>\t<content>" | sha256sum | base64 as the Twt Subject or concatenating the <url> <timestamp> – The “effort” is the same. If we’re going to argue that SHA256 or cryptographic hashes are “too complicated” then I’m not really sure how to support that argument.

👋 Reminder folks of the upcoming Yarn.social monthly online meetup:

I hope to see @david@collantes.us @movq@www.uninformativ.de @lyse@lyse.isobeef.org @xuu@txt.sour.is @sorenpeter@darch.dk and hopefully others too @aelaraji@aelaraji.com @falsifian@www.falsifian.org and anyone else that sees this! 🙏 We’re hopefully going to primarily discuss the future of Twtxt and the last few weeks of discussions 🤣

• Event: Yarn.social Online Meetup
  
• When: 28th September 2024 at 12:00pm UTC (midday)
  
• Where: Mills Meet : Yarn.social
  
• Cadence: 4th Saturday of every Month
  

Agenda:

• Let’s talk about the upcoming changes to the Twtxt spec(s)
  
  • See #xgghhnq
    

#Yarn.social #Meetup

Alright, before I go and watch Formula 1 😅, I made two PRs regarding the two “competing” ideas:

• https://git.mills.io/yarnsocial/yarn/pulls/1179 – (replyto:…)
  
• https://git.mills.io/yarnsocial/yarn/pulls/1180 – (edit:…) and (delete:…)
  

As a first step, this summarizes my current understanding. Please comment! 😊

@lyse@lyse.isobeef.org yeah, tell us, @prologic@twtxt.net, what isn’t true? 🤔 You can’t just go around, “that’s not true, and that’s not true; and that, and that!” without spelling out exactly what isn’t, and why? For the love of god, why?! 😂

@prologic@twtxt.net cool, I will be there! Are you going to post the regular banner notice? It will serve as a reminder, at least for me.

I wrote some code to try out non-hash reply subjects formatted as (replyto ), while keeping the ability to use the existing hash style.

I don’t think we need to decide all at once. If clients add support for a new method then people can use it if they like. The downside of course is that this costs developer time, so I decided to invest a few hours of my own time into a proof of concept.

With apologies to @movq@www.uninformativ.de for corrupting jenny’s beautiful code. I don’t write this expecting you to incorporate the patch, because it does complicate things and might not be a direction you want to go in. But if you like any part of this approach feel free to use bits of it; I release the patch under jenny’s current LICENCE.

Supporting both kinds of reply in jenny was complicated because each email can only have one Message-Id, and because it’s possible the target twt will not be seen until after the twt referencing it. The following patch uses an sqlite database to keep track of known (url, timestamp) pairs, as well as a separate table of (url, timestamp) pairs that haven’t been seen yet but are wanted. When one of those “wanted” twts is finally seen, the mail file gets rewritten to include the appropriate In-Reply-To header.

Patch based on jenny commit 73a5ea81.

https://www.falsifian.org/a/oDtr/patch0.txt

Not implemented:

• Composing twts using the (replyto …) format.
  
• Probably other important things I’m forgetting.

@eldersnake@we.loveprivacy.club I wanted to ask you, are you running Headscale and WireGuard on the same VPS? I want to test Headscale, but currently run a small container with WireGuard, and I wonder if I need to stop (and eventually get rid of) the container to get Headscale going. Did you use the provided .deb to install Headscale, or some other method?

@eldersnake@we.loveprivacy.club there has to be less reliance on a single point of failure. It is not so much about creating jobs in the US (which come with it, anyway), but about the ability to produce what’s needed at home too. What’s the trade off? Is it going to be a little bit more expensive to manufacture, perhaps?

I have configured my twtxt.txt as simple as possible. I have setup a publish_command on jenny. Hopefully all works fine, and I am good to go. Next will be setting the announce_me to true. Here we go!

@movq@www.uninformativ.de going a little sideways on this, “*If twtxt/Yarn was to grow bigger, then this would become a concern again. But even Mastodon allows editing, so how much of a problem can it really be? 😅*”, wouldn’t it preparing for a potential (even if very, very, veeeeery remote) growth be a good thing? Mastodon signs all messages, keeps a history of edits, and it doesn’t break threads. It isn’t a problem there.😉 It is here.

I think keeping hashes is a must. If anything for that “feels good” feeling.

Hey, @movq@www.uninformativ.de, a tiny thing to add to jenny, a -v switch. That way when you twtxt “That’s an older format that was used before jenny version v23.04”, I can go and run jenny -v, and “duh!” myself on the way to a git pull. :-D

Regarding jenny development: There have been enough changes in the last few weeks, imo. I want to let things settle for a while (potential bugfixes aside) and then I’m going to cut a new release.

And I guess the release after that is going to include all the threading/hashing stuff – if we can decide on one of the proposals. 😂

@prologic@twtxt.net the real conclusion is, is it going to change, to what, and when? :-P

@lyse@lyse.isobeef.org fully agree. I have never been a fan of relative times to begin with, so that one will go away, foh sho! :-D