@nghialele it’s great to see another Yarnd pod in the wild. Welcome!

@sorenpeter you wrote:

"This might even be backward compatible with older (pre-yarn) clients."

Yarnd is as backwards compatible with older clients as this. I dare to say, even more so. 😅

Going to try and few up a few more UX bugs today with yarnd.

I wonder if this twtxt will kick Yarnd into working again. There is only one way to find out, right?

After yarnd v0.16 is released and the next round of specification updates are done and dusted, who wants me to have another crack at building Twtxt and activity pub integration support?

@prologic I have:

• jenny
• buckket's original (patched, or not)
• tt/tt2
• Timeline
• Twtxtory
• Yarnd

I will be adding the code in for yarnd very soon™ for this change, with a if the date is >= 2025-07-01 then compute_new_hashes else compute_old_hashes

@bender Hehe good sleuthing 🤣 I swear it was an edit ✍️ Haha 😂 yarnd now "sees" both every single time, where-as before it would just obliterate the old Twt, but remain in archive. Now you get to see both 😅 Not sure if that's a good thing or not, but it certainly makes it much clearer how to write "code logic" for detecting edits and doing something more UX(y) about 'em 🤔

Interesting edit observed by the new yarnd powering this pod twtxt.net 🧐

Today I added support for Let's Encrypt to eris via DNS-01 challenge. Updated the gcore libdns package I wrote for Caddy, Maddy and now Eris. Add support for yarn's cache to support # type = bot and optionally # retention = N so that feeds like @tiktok work like they did before, and... Updated some internal metrics in yarnd to be IMO "better", with queue depth, queue time and last processing time for feeds.

Interesting factoid... By inspecting my "followers" list every now and again, I can tell who uses a client like jenny, tt or any other client where fetches are driven by user interactions of invoking the app. What do we call this type of client? Hmmm 🤔 Then I can tell who uses yarnd because they are "seen" more frequently 🤣

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

I’m thinking of building a hardened peering protocol for Yarn.social’s yarnd: pods establish cryptographic identities, exchange signed /info and /twt payloads with signature verification, ensuring authenticity, integrity, and spoof-proof identity validation across the distributed network.

@eapl.me I wouldn't call it natural, it is the way Bluesky decided to handle handles (not meaning to make a pun, or anything). There is no other way, but that.

The bottomline is, there are agreed upon "standards", right? From example, on Yarnd you show as "eapl.me", from "eapl.me". A kind of weird redundancy because on twtxt, ever since I started using it, one will expect to see a "nick" (equivalent to a person's first name), from "a domain" (like a surname).

There is nothing holding back someone from giving themselves the nick:

thisismyawesomenickforwhichiwillbeknownforeverandeveritsgreatisntit

But, do we really want that? 😅

@kat OMG! You used the video capabilities of yarnd 🤣 Nice! 😊

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

@prologic why not blanket closing everything older than, say, 3 months? Yarnd is quite a different beast today, right? Let's start over!

@bender You said:

as long as those working on clients can reach an agreement on how to move forward. That has proven, though, to be a pickle in the past.

I think this is because we probably need to start thinking about three different aspects to the ecosystem and document them out:

• Specifications (as they are now)
• Server recommendations (e.g: Timeline, yarnd, etc)
• Client recommendations (e.g: jenny, tt, tt2, twet, etc)

@lyse oh, and thanks for the bigger photo! I like how it lovely fill the twtxt in Yarnd. Woot!

All these remind me of the "blog" ability once existed in Yarnd. I hate to be the party pooper, but little to non interest from me. LOL. I am up to increase the length of a twtxt, though. It is rather limiting right now.

The nice thing here is that any Ui/UX rendering for a "good user experience" is similar to what yarnd does for Youtube/Spotify/whatever embedding. Plus anyone can participate, even if they don't really have a client that understand it, it's just text with some "syntax" afterall.

💡 I had this crazy idea (or is it?) last night while thinking about Twtxt and Yarn.social 😅 There are two things I think that could be really useful additions to the yarnd UI/UX experience (for those that use it) and as "client" features (not spec changes). The two ideas are quite simple:

• Voting -- a way to cast, collect a vote on a decision, topic or opinion.
• RSVP -- a way to "rsvp" to a virtual (pr physical) event.

Both would use "plain text" on top of the way we already use Twtxt today and clients would render an appropriate UI/UX.

@andros I don't see any "fighting" here. This is just good experimentation. Unfortunately there hasn't really been enough time or effort by other "client authors" yet, me especially as I've been super busy with ya' know my "day job" that pays the bills and refactoring yarnd to use a new and shiny and much better SqliteCache 🤣 -- I certainly don't think your efforts are wasted at all. I would however like @doesnm.p.psf.lt encourage you to look at the work we've done as a community (which was also driven out of the Yarn.social / Twtxt community years back).

@bender You will be pleased to know that yarnd now only consumes ~60-80MB of memory depending on load 🤣 And bugger all CPU 😅

Hmm, Yarnd is duplicating the rendering of /twt/5jlfuua. That's quite odd.

I'm so confused. None of this code has changed in yarnd at all. Hmmm 🤔

I'm thinking you may have edited. Lemme check actually... yarnd (on this branch) will now restore every version, and maybe I might have introduced a bit of a weird behavior there. One moment...

@prologic All the URL are missing the protocol part (https://) and my markdown parser does not know how to handle but I see yarnd does it just fine.

Are we talking about profile view heading, heading of posts or inline mentions? In yarnd I recall there is a setting for changing the heading of posts, but not for the two others as of yet. I like the hover option for inline mentions. For the other places some like how yarnd does it in two line or " nick (domain.tld) " could also work.

@prologic Well I just mirrored yarnd's JSON in my webfinger endpoint and lookup, so not much else to do for standardization.

And for people who don't like PHP you can always just go with Added WebFinger support to my email address using one rewrite rule and one static file. or simply putting a static JSON in place for .well-know/webfinger

I like the cleaness and indiewebness of using just domains for handles/shorthands similar to blusky, but the situations with more users on the same domain and that people in the fediverse (threads too?) are already familiar with the syntax speaks for webfinger. And since we already got support for webfinger in both yarnd and timeline it makes sense to stick with it.

(#<2024-09-24T12:34:31Z https://twtxt.net/user/prologic/twtxt.txt>) WebMentions does would work if we agreed to implement it correctly. I never figured out how yarnd's WebMentions work, so I decide to make my own, which I'm the only one using...

I had a look at WebSub, witch looks way more complex than WebMentions, and seem to need a lot more overhead. We don't need near realtime. We just need a way to notify someone that someone they don't know about mentioned or replied to their post.

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?

It not that easy @xuu since I implemented webmentions in a different way that how it have been done in yarnd to work with txt-files. You can find the code in webmention_endpoint.php and new_twt.php at main · sorenpeter/timeline

Also made a webfinger lookup resolver that works with my own webfinger endpoint as well as yarnd servers: http://darch.dk/wf-lookup.php

I'm also more in favor of #reposts being human readable and writable. A client might implement a bottom that posts something simple like: <a href="?search=repost" class="tag">#repost</a> Look at this cool stuff, because bla bla [alt](url)

This will then make it possible to also "repost" stuff from other platforms/protocols.

The reader part of a client, can then render a preview of the link, which we talked about would be a nice (optional) feature to have in yarnd.