Searching yarn

Twts matching #yarnsocial
Sort by: Newest, Oldest, Most Relevant
In-reply-to » @prologic I really like how these two apps pair-up. Seeing as I'm still tweaking TwtKpr, I'm considering adding support for the same APIs as twtd (so maybe it can be used as another backend for Twtxt.App). 🤔

@itsericwoodward@itsericwoodward.com Wrote it up 👌 Single-user twtd API is now documented (plain JSON, one bearer token) — posting, uploads, profile, followers + WebFinger: https://git.mills.io/yarnsocial/twtd/src/branch/main/API.md 🎉 Shout if anything’s unclear for TwtKpr 🙏

⤋ Read More
In-reply-to » New in the Twtxt App 🥳 a Hosted feed backend — claim a nick, one tap, no account, no server, nothing to run. Your feed lives at https://twtpub.com/u/yournick and you're posting from the app straight away 🎉

twtpub.com is just the default instance tho — it’s a multi-tenant twtd, AGPLv3. Run your own and I’ll list it in the app’s picker so folks choose where to land 🤗 keeps it decentralised + spreads the load. Docs → https://git.mills.io/yarnsocial/twtd

⤋ Read More

🥳 Finally! After nearly 4 years, yarnd v0.16.0 “Silver Sojourner” is out! 🚀 Twt Hash v2, SQLite FTS5 search, HTMX-powered UI, first-time setup wizard and literally hundreds of bug fixes 🐛

Release notes: https://git.mills.io/yarnsocial/yarn/releases/tag/0.16.0

Upgrading is fully automatic — the Twt Hash v2 migration re-fetches all feeds on first start, so expect the first cycle to be a bit heavier. Images on Docker Hub as prologic/yarnd:0.16.0 👌

cc @kat@yarn.girlonthemoon.xyz @abucci@anthony.buc.ci @shinyoukai@yume.laidback.moe @eldersnake@we.loveprivacy.club 🙏

⤋ Read More
In-reply-to » The original twt is unavailable. It may have been edited or deleted, or is from an unknown or muted feed.

@david@daiwei.me as you alter ego, I seriously recommend you stop creating feeds left and right. But whom am I kidding, right?! 😅

I wonder how long will it take to show a follower on twtd. It only shows the feed’s owner, so far.

⤋ Read More

Hello everyone ! 👋 Behold I bring you (after many years) the launch of the Twtxt App 😅 – Ye, this is a Desktop and Mobile app built as a Progressive Web App (PWA) using a little framework (Swag) I put together iafter some experiments @xuu@txt.sour.is and I did in Go and HTMX and Service Workers.

The App is offline-first and supports installing to Desktop and Mobile (add to Home screen) and supports a number of publishing backends, including Yarn.social’s yarnd Pod, Github, Codeberg/Gitea, and a little tiny twtd Twtxt server (See: https://git.mills.io/yarnsocial/twtd).

Please try it out, no need for any account(s) or such, works with your existing feed(s) (as long as the publishing backends work well enough for you!). Please give me feedback! 🙏

Also, did you know the Twtxt Search Engine is back? 🎉

⤋ Read More

All my newly added test cases failed, that movq thankfully provided in https://git.mills.io/yarnsocial/twtxt.dev/pulls/28#issuecomment-20801 for the draft of the twt hash v2 extension. The first error was easy to see in the diff. The hashes were way too long. You’ve already guessed it, I had cut the hash from the twelfth character towards the end instead of taking the first twelve characters: hash[12:] instead of hash[:12].

After fixing this rookie mistake, the tests still all failed. Hmmm. Did I still cut the wrong twelve characters? :-? I even checked the Go reference implementation in the document itself. But it read basically the same as mine. Strange, what the heck is going on here?

Turns out that my vim replacements to transform the Python code into Go code butchered all the URLs. ;-) The order of operations matters. I first replaced the equals with colons for the subtest struct fields and then wanted to transform the RFC 3339 timestamp strings to time.Date(…) calls. So, I replaced the colons in the time with commas and spaces. Hence, my URLs then also all read https, //example.com/twtxt.txt.

But that was it. All test green. \o/

⤋ Read More
In-reply-to » TNO Threading (draft):
Each origin feed numbers new threads (tno:N). Replies carry both (tno:N) and (ofeed:<origin-url>). Thread identity = (ofeed, tno).

@prologic@twtxt.net I think a counter in the client is not a good choice given the decentralized nature of twtxt, especially if someone use multiple cients together.

After thinking about it for a while I got to two solutions:

Proposal 1: Thread syntax (using subject)

Each post have an implicit and an optional explicit root reference:

  • Implicit (no action needed, all data required are already there)

    • URL + timestamp
  • Explicit (subject required)

    • Identity (client generated)
    • External reference
    • Random value

We then add include a “root” subject in each post for generating explicit theads:

1. `[ROOT_ID] (REPLY_ID)`: simpler with no need of prefixes
2. `(root:ROOT_ID) (reply:REPLY_ID)`: more complex but could allow expansions
	- `(rt:ROOT_ID) (re:REPLY_ID)`: same but with a compact version
	- `($ROOT_ID) (>REPLY_ID)`: same but with a single characters

Each post can have both references, like the current hash approach the reference can be treated as a simple string and don’t have a real meaning.

Using a custom reference this way allows a client to decide how to generate them:

  • Identity: can be a content hash or signature or anything else, without enforcing how it is generated we can upgrade the algorithm/length freely
  • External references: can be provided from another system (Eg. 7e073bd345, yarnsocial/yarn latest commit)
  • Random value: like a UUID (Eg. 9a0c34ed-d11e-447e-9257-0a0f57ef6e07)

Proposal 2: Threaded mentions (featuring zvava)

Inspired by @zvava@twtxt.net’s solution it could be simplified into: #<nick url#timestamp> or #<url#timestamp>

It can be shown like a mentions or hidden like a subject.

If we’re using thinking of using a counter in the client, I think there’s no point in avoiding the timestamp anymore.

⤋ Read More
In-reply-to » @zvava love the direction this is heading, hope this soon evolves into a basic Android app, usable with any instance.

@zvava@twtxt.net Not much of a known fact these days, but thereused to be a Yarn phone app (https://git.mills.io/yarnsocial/app), last version released 5 or so years ago, but it still suggests, it has to be somewhat feasable, to make another one. I don’t think anyone tried since, because the web version works well on phones, but I’m still hoping, we get a more native phone experience, one day.

⤋ Read More
In-reply-to » 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

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

⤋ Read More
In-reply-to » 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

https://git.mills.io/yarnsocial/twtxt.dev/pulls/28

⤋ Read More

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@feeds.twtxt.net 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.

⤋ Read More
In-reply-to » @xuu or @kat Do either of you have time this weekend to test upgrading your pod to the new cacher branch? 🤔 It is recommended you take a full backup of you pod beforehand, just in case. Keen to get this branch merged and to cut a new release finally after >2 years 🤣

@kat@yarn.girlonthemoon.xyz Yes see UPGRADE.md – I believe @xuu@txt.sour.is is now running this live after a couple of hiccups and a bug fix. So yeah if you can, that would be cool, basically looking for early beta testers (I was the alpha tester 🤣)

⤋ Read More
In-reply-to » Hi! For anyone following the Request for Comments on an improved syntax for replies and threads, I've made a comparative spreadsheet with the 4 proposals so far. It shows a syntax example, and top pros and cons I've found: https://docs.google.com/spreadsheets/d/1KOUqJ2rNl_jZ4KBVTsR-4QmG1zAdKNo7QXJS1uogQVo/edit?gid=0#gid=0

@eapl.me@eapl.me Cool!

Proposal 3 (https://git.mills.io/yarnsocial/twtxt.dev/issues/18#issuecomment-19215) has the “advantage”, that you do not have to “mention” the original author if the thread slightly diverges. It seems to be a thing here that conversations are typically very flat instead of trees. Hence, and despite being a tree hugger, I voted for 3 being my favorite one, then 2, 1 and finally 4.

All proposals still need more work to clarify the details and edge cases in my opinion before they can be implemented.

⤋ Read More
In-reply-to » 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.

it seems to be confused with the subject right next to it.. it works better at the end of the twt string.
Yarn won’t display anything. but the parser does add it to the AST in a way that you can parse it out using twt.Attrs().Get("lang")

https://git.mills.io/yarnsocial/go-lextwt/src/branch/main/ast.go#L1270-L1272

https://git.mills.io/yarnsocial/go-types/src/branch/main/twt.go#L473-L478

⤋ Read More
In-reply-to » @bender @prologic I can reproduce this locally, too. But it doesn't matter if I follow the feed or not. With JS enabled, hitting "Reply" opens a textarea with @<url>. Submitting this writes @<domain url> instead of @<nick url> in the feed.

While I now have a somewhat working fix for it in yarnd (https://git.mills.io/yarnsocial/yarn/pulls/1232), I also have the feeling that I should fix literal formatting in lextwt as well. This also uncovered more bugs I believe: https://git.mills.io/yarnsocial/go-lextwt/pulls/28

But then there is also the question why the textarea is populated with @<url> in the first place rather than @<nick url> or yarnd’s own @nick@domain/@nick syntax. It indeed has to do something with whether I follow the mentioned feed or not.

Anyway, something to investigate for future Lyse or maybe @prologic@twtxt.net and/or @xuu@txt.sour.is. G’night!

⤋ Read More