fit 1 $ spin (saw 0.1 * sign fxy) $ rect 0 1 - rect 0 0.99 >> add; #punctual #livecoding #creativecoding #videoart

@lyse what is the advantage for keeping it small? Will tt/tt2 bog down if your feed isn't rotated?

@javivf Sorry. 😂 Meet me on IRC at irc.mills.io in #edgeguard 👌 I'm @james there 😅

Farrrk me Google search is and these days. Will they please "fuck off" with this Gemini AI garbage at the top that takes forever and is distracting as shit™ 💩 Fark me 🤦‍♂️ #Google #Search #Sucks #AI #Gemini

Move beyond basic threshold alerts! Define clear Service Level Objectives (SLOs) and measure Service Level Indicators (SLIs) to track real user impact. Use Prometheus to alert when your SLOs are at risk, ensuring you focus on what truly matters to your users. #Monitoring #SRE #Prometheus

July 1st. 63 days from now to implement a backward-incompatible change, apparently not open to other ideas like replacing blake with SHA, or discussing implementation challenges for other languages and platforms. Finally just closing #18, #19 and #20 without starting a proper discussion and ignoring a 'micro consensus' feels... not right.

I don't know what to think rather than letting it rest (May will be busy here) and focus on other stuff in the future.

twt-hash-v2.md#implementation-timeline

Finally I propose that we increase the Twt Hash length from 7 to 12 and use the first 12 characters of the base32 encoded blake2b hash. This will solve two problems, the fact that all hashes today either end in q or a (oops) 😅 And increasing the Twt Hash size will ensure that we never run into the chance of collision for ions to come. Chances of a 50% collision with 64 bits / 12 characters is roughly ~12.44B Twts. That ought to be enough! -- I also propose that we modify all our clients and make this change from the 1st July 2025, which will be Yarn.social's 5th birthday and 5 years since I started this whole project and endeavour! 😱 #Twtxt #Update

And speaking of Twtxt (See: #xushlda, feeds should be treated as append-only. Your client(s) should be appending Twts to the bottom of the file. Edits should never modify the timestamp of the Twt being edited, nor should a Twt that was edited by deleted, unless you actually intended to delete it (but that's more complicated as it's very hard to control or tell clients what to do in a truely decentralised ecosystem for the deletion case). #Twtxt #Client #Recommendations

Just like we don't write emails by hand anymore (See: #a3adoka), we don’t manually write Twts or update our twtxt.txt feeds. Instead, we use modern Twtxt clients that conform to the specifications at Twtxt.dev for a seamless, automated experience. #Twtxt #Twt #UserExperience

Nobody writes emails by hand using RFC 5322 anymore, nor do we manually send them through telnet and SMTP commands. The days of crafting emails in raw format and dialing into servers are long gone. Modern email clients and services handle it all seamlessly in the background, making email easier than ever to send and receive—without needing to understand the protocols or formats behind it! #Email #SMTP #RFC #Automation

First draft of yarnd 0.16 release notes. 📝 -- Probably needs some tweaking and fixing, but it's sounding alright so far 👌 #yarnd

by commenting out DMs are you giving up on simplicity? See the Metadata extension holding the data inside comments, as the client doesn't need to show it inside the timeline.

I don't think that commenting out DMs as we are doing for metadata is giving up on simplicity (it's a feature already), and it helps to hide unwanted DMs to clients that will take months to add it's support to something named... an extension.

For some other extensions in https://twtxt.dev/extensions.html (for example the reply-to hash <a href="?search=abcdfeg" class="tag">#abcdfeg</a> or the mention @ < example http://example.org/twtxt.txt >) is not a big deal. The twt is still understandable in plain text. For DM, it's only interesting for you if you are the recipient, otherwise you see an scrambled message like 1234567890abcdef=. Even if you see it, you'll need some decryption to read it. I've said before that DMs shouldn't be in the same section that the timeline as it's confusing.

So my point stands, and as I've said before, we are discussing it as a community, so let's see what other maintainers add to the convo.

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

Regex Isn't Hard - Tim Kellogg 👈 this is a pretty good conscience article on regexes, and I agree, regex isn't that hard™ -- However I think I can make the TL;DR even shorter 😅

Regex core subset (portable across languages):

Character sets • a matches “a” • [a-z] any lowercase • [a-zA-Z0-9] alphanumeric • [^ab] any char but a or b

Repetition (applies to the preceding atom) • ? zero or one • * zero or more • + one or more

Groups • (ab)+ matches “ab”, “abab”, … • Capture for extract/substitute via $1 or \1

Operators • foo|bar = foo or bar • ^ start anchor • $ end anchor

Ignore non‑portable shortcuts: \w, ., {n}, *?, lookarounds.

#regex101

#event:abc123 RSVP: yes +1

#event:abc123 Go Meetup – Sat Apr 27, 3pm @ Darling Harbour

#poll:xyz123 Vote: None

#poll:xyz123 Favorite Go framework?

• Gin
• Echo
• Chi

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 = <a href="?search=37sjhla" class="tag">#37sjhla</a>
  mentions = []
      tags = []
     links = []
sqlite>

@andros Curious where this root twt is?! 🤣 Apparently my pod doesn't have it and I can't find it anywhere. It's suppose to be <a href="?search=l4doaxa" class="tag">#l4doaxa</a>

This on vp-compact.css:

.avatar:not(<a href="?search=profile" class="tag">#profile</a>-avatar .avatar) {
    width: 2rem !important;
    height: 2rem !important;
    margin-top: -0.25rem !important;

}

Is colliding with yarn.min.css:

.avatar, .avatar-full {
    width: 3.5rem;
    height: 3.5rem;
    object-fit: cover;
    border-radius:var(--border-radius)
}

I'm also thinking that some kind of tag might be needed to automatically hide twts from unknown extensions. For example our client doesn't support DMs and always shows the !<nick url><encrypted_message> syntax which is meaningless.

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 = (<a href="?search=znf6csa" class="tag">#znf6csa</a>)
mentions = []
    tags = []
   links = []

Ahhh! It's all Soren's fault 🤣

commit ea9eaaf3d3977701dcb84b927c77c4f921bdbf43
Author: sorenpeter <sorenpeter@noreply@mills.io>
Date:   Sat Sep 24 23:34:07 2022 +0000

    Replacing Pico.css with Simple.css (<a href="?search=990" class="tag">#990</a>)

    Replacing pico.css with simple.css along with some small UI changes

FYI: I've re-opened up search for anonymous use. So things like this now work without having to have an account on this pod or login. 👌 #search #twtxt

pls elaborate on a 'p2p database', 'all story' and 'Registries'.

My first thought takes me to something like secure-scuttlebutt which it's painful to sync data using clients, and too slow compared to downloading a text file.

Also I'd like for twtxt to avoid becoming an ActivityPub. Works well but it's uses too many resources IMO. https://kingant.net/2025/02/mastodon-the-cost-of-running-my-own-server/

I'm defending being able to self-host your Web client (like you'd do with a Wordpress, twtxt is a micrologging, at the end), instead of federated instances, so in a first thought I'd say Registries have many disadvantages being the first one that someone has to maintain them active.

#testing @Bob Hi Bob, nice to meet you!

[lang=en] @xuu gotcha! From that PR #17 I think it was reverted? We could discuss about metadata later this month, as it seems that I'm the only person using it.

I've added a [lang=en] to this twt to see current yarn behaviour.

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

Added support for uploading images to to #Timeline Right now you need to copy the markdown code yourself, but next up would be to lean some JS or use HTMX to make the process more smooth.

that's a fair point.

Perhaps, since Twitter in 2006 never implemented read flags, every derivative microblogging system never saw that as an expected feature. This is curious because Twitter started with SMS, where on our phones we can mark messages as read or unread. I think it all comes from the difference between reading an email (directed to you) vs. reading public posts (like a blog or a 'wall,' where you don't mark posts as read). It's not necessary to mark it as 'read', you just jump over it.

Reading microblogging posts in an email program is not common, I think, and I haven't really used it, so I cannot say how it works, and whether it would be better for me or not. However, I've used Thunderbird as a feed reader, and I understand the advantages when reading blog posts.

About read flags being simple, well... we just had a discussion this morning about how tracking read messages would require a lot of rethinking for clients such as timeline where no state is stored. Even considering some kind of 'notification of unread messages or mentions' is not expected for those minimalist client, so it's an interesting compromise to think about.

#genuary #genuary2025 #genuary17 Maybe related to today prompt: What happens if pi=4? https://youtu.be/tGfUaZ8hTzg

although I agree that it helps, I don't see completely correct to leave the nick definition to the source .txt. It could be wrong from the start or outdated with the time.

I'd rather prefer to get it from the mentioned .txt nick metadata (could be cached for performance). So my vote would to make it mandatory to follow <a href="/profile?url=url">@name</a> but only using that name/nick if the URL doesn't contain another nick. A main advantage is that when the destination URL changes the nick, it'll be automagically updated in the thread view (as happens with some other microblogging platforms, following the Jakob's Law)

What should the advantage be to nick = _compared to just not defining a nick and let the client use the domain as the handle?

What is not intuitive is that you put something in the nick field that is not to be taken literary. The special meaning of _ is only clean if you read the documentation, compared to having something in nick that makes sense in the current context of the twtxt.txt.

haha, that's gold xD.

#randomMemory I remember when I was starting to code, like 30 years ago, not understanding why my Basic file didn't run when I renamed it to .exe

And nowadays, I've seen a few Go apps in a single executable, so twtxt.exe could be a thing, he!

Wow, it seem my #Webmentions implementation works from Mastodon via brid.gy

My twtAgent.php was turned off, so try again now. I have uploaded the code to: https://github.com/sorenpeter/twtAgent

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

@eapl.mx Yes, the idea is to add User Agent support to #Timeline. Right now it just adds every request to a growing log file, but I have also been working on a way to analyse it, so it only saves the time of the latest request. I'm not sure how to make it part of timeline itself, since it requeses that you redirect/rewrite from twtAgent.php to the acctual twtxt.txt Help with making Timeline send proper User Agents to others would be much appreciated:)

"A minimalist social network powered by plain text files" - my talk about #twtxt from #Piksel24 Festival is now on YouTube and slides can be found at http://darch.dk/twtxtalk-piksel

@bender The tagline of Timeline is "a single user twtxt/yarn pod" not just a yarn pod. Similar to GNU/Linux. When we came up with the concept of Yarn Social it was a way to rebrand twtxt with the extensions that makes conversations like this possible.

Great to see another user @aelaraji - And I can confirm that my #webmentions works from your server (I know, the formatting is messed up;)

Seven Bit Encoding by Dylan Beattie #music

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

What are peoples #IRC setup? Do you have your own bouncer server or just have a you computer always on? And do you IRC on mobile?

@movq How hard would it be to implement something like (#<2024-10-25T17:15:50Z https://www.uninformativ.de/twtxt.txt>)in jenny as a replacement for (<a href="?search=twthash" class="tag">#twthash</a>) and have it not care about if is http(s) or a g-protocol?

Video of my latest #livecoding show using #punctual for #visuals https://www.youtube.com/watch?v=CsM39SpRik8

Some more arguments for a local-based treading model over a content-based one:

1. The format: `or(@DATE)both makes sense: # as prefix is for a hashtag like we allredy got with the(#twthash)` and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.

2. Having something like `will also make mentions via [webmetions for twtxt](https://darch.dk/mentions-twtxt) easier to implement, since there is no need for looking up the#twthash`. This will also make it possible to make 3th part twt-mentions services.

3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don't follow.

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?

I just "published" a #draft on my blog about "How I've implemented #webmentions for twtxt" (http://darch.dk/mentions-twtxt), so I wanted to know from you guys if you see yourself doing a similar thing with yarnd @prologic or others with custom setups?