When I try to login to PayPal I now see:

Please enable JS and disable any ad blocker

Here's the thing. PayPal takes fees from transactions and payments received and sent.

I have very right not have ads shoved in my face for something that isn't actually free in the first place and costs money to use. If PayPal would like to continue to piss off folks me like, then I'll happily close my PayPal account and go somewhere else that doesn't shove ads in my face and consume 30-40% of my Internet bandwidth on useless garbage/crap.

#PayPal #Ads

@therealprologic It works! 🤣 Now I'm quite sure we haven't got threads working yet 🤔

Like these Car Manufacturers, like GWM, Toyota, Mercedes, BMW and whoever else does this stupid shit™ need to pull their heads out of their asse. :O

@zvava Going to have to hard disagree here I'm sorry. a) no-one reads the raw/plain twtxt.txt files, the only time you do is to debug something, or have a stick beak at the comments which most clients will strip out and ignore and b) I'm sorry you've completely lost me! I'm old enough to pre-date before Linux became popular, so I'm not sure what UNIX principles you think are being broken or violated by having a Twt Subject (Subject) whose contents is a cryptographic content-addressable hash of the "thing"™ you're replying to and forming a chain of other replies (a thread).

I'm sorry, but the simplest thing to do is to make the smallest number of changes to the Spec as possible and all agree on a "Magic Date" for which our clients use the modified function(s).

@alexonit My problem is I don't see a world where we don't employ some form of cryptography to use as keys for threads in databases and other such things honestly. I'm not going to use url#timestamp as keys.

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

• Roots: (tno:N) (implicit ofeed=self).
• Replies: (tno:N) (ofeed:<url>).
• Clients: increment tno locally for new threads, copy tags on reply.
• Subjects optional, not required.

...

Here is just a small list of things™ that I'm aware will break, some quite badly, others in minor ways:

1. Link rot & migrations: domain changes, path reshuffles, CDN/mirror use, or moving from txt → jsonfeed will orphan replies unless every reader implements perfect 301/410 history, which they won’t.
2. Duplication & forks: mirrors/relays produce multiple valid locations for the same post; readers see several “parents” and split the thread.
3. Verification & spam-resistance: content addressing lets you dedupe and verify you’re pointing at exactly the post you meant (hash matches bytes). Location anchors can be replayed or spoofed more easily unless you add signing and canonicalization.
4. Offline/cached reading: without the original URL being reachable, readers can’t resolve anchors; with hashes they can match against local caches/archives.
5. Ecosystem churn: all existing clients, archives, and tools that assume content-derived IDs need migrations, mapping layers, and fallback logic. Expect long-lived threads to fracture across implementations.

On the configuration topic, the example at the repo reads like this:

``

I use Headscale. Love it!

@itsericwoodward Also just a heads up, GIF(s) aren't supproted as an Avatar type on yarnd (what runs twtxt.net). I'd change this to something that's more supproted like PNG, JPEG, etc.

After many weeks and probably at least a hundred hours of research, discussions and in-person viewing, I think I've finally come up with my Final Choices (shortlist) of a Hybrid Camper / Caravan that I think will suit my family and that I'll enjoy (far less work for me to setup and teardown). The one at the top of the list I'm leaning towards os the SWAG SCT16 Family 4B #Camping #Campers

@prologic do you remember Hamachi? Tailscale/Headscale is Hamachi on steroids. They are used primarily for creating a VPN among all your devices so they can talk to one another as if they were on the same LAN, even when they're not. That was, mostly, my WireGuard usage.

I still have WireGuard running—because it is so lite that it doesn’t matter—to use as regular VPN, but Headscale keeps all my devices connected forming their own “mini-Internet” 100% of the time.

@prologic Tailscale is awesome! I run Headscale; it replaced my vanilla WireGuard install.

@prologic yeah, that will work perfectly. Because you are using “please”—which we all know is a magic talisman word of obedience—all uploads of your code to Github will be automatically paused, until such magic word is removed. 😂

One of the nicest things about Go is the language itself, comparing Go to other popular languages in terms of the complexity to learn to be proficient in:

• Go: 25 keywords (Stack Overflow); CSP-style concurrency (goroutines & channels)
• Python 2: 30 keywords (TutorialsPoint); GIL-bound threads & multiprocessing (Wikipedia)
• Python 3: 35 keywords (Initial Commit); GIL-bound threads, asyncio & multiprocessing (Wikipedia, DEV Community)
• Java: 50 keywords (Stack Overflow); threads + java.util.concurrent (Wikipedia)
• C++: 82 keywords (Stack Overflow); std::thread, atomics & futures (en.cppreference.com)
• JavaScript: 38 keywords (Stack Overflow); single-threaded event loop & async/await, Web Workers (Wikipedia)
• Ruby: 42 keywords (Stack Overflow); GIL-bound threads (MRI), fibers & processes (Wikipedia)

@andros Thanks for consolidating a lot of good ideas. Especially how you have deiced to just extend the mention syntax for location-based treads. This might even be backward compatible with older (pre-yarn) clients. What about using Z for UTC +00:00- is that allowed in your specs? Regarding url = I would suggest to only allow one and the maybe add url_old = or url_alt = !? I'm still not a fan of a DM feature, even thou it helps that i have now been split out into a separate feed file. Instead if would suggest a contact = field for where people can put an email or other id/link for an established chat protocol like signal or matrix.

@andros what makes Kagi "the best search engine"? It is premium, alright. Allegedly you don't get ads, but pay up-front for it, monthly.

@lyse haha, not satire. It is also in Mark Twain’s “Huckleberry Finn” as well:

"If fifteen cows is browsing on a hillside, how many of them eats with their heads pointed the same direction?"

"The whole fifteen, mum."

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.

I asked ChatGPT what it knows about Twtxt 😂 And surprisingly it's rather accurate:

Twtxt is a minimalist, decentralized microblogging format introduced by John Downey in 2016. It uses plain text files served over HTTP—no accounts, databases, or APIs. In 2020, James Mills (@prologic) launched Yarn.social, an extended, federated implementation with user discovery, threads, mentions, and a full web UI. Both share the same .twtxt.txt format but differ in complexity and social features.

well, that leads to a long conversation.

Piracy is a difficult topic which is very personal, so I won't say much about it.

On writing books, I've tried along with other digital products such as courses and videogames, and I got to confess that it has been hard for me.

If it helps, I think it all reaches our expectations on the activity and the result. If royalties is the expectation, it's going to be slow. By 5% of royalties, for a rough example, a huge amount of sales will be required to get a decent "wage", so I've understood of doing it by the side of a normal employment although it has been discouraging and a bit sad.

I have reflected about it in Spanish here: https://sembrandojuegos.substack.com/p/sobre-expectativas-al-crear-juegos

For anyone following the proposals to improve replies and threads in twtxt, the voting period has started and will be open for a week. https://eapl.me/rfc0001/

Please share the link with the twtxt community, and leave your vote on your preferred proposals, which will be used to gauge the perceived benefits.

Also, the conversation is open to discuss implementation concerns or anything aimed at making twtxt better.

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

Feel free to propose another collaborative platform (for those without a G account), and also share your comments and analysis in the spreadsheet or in Gitea.

well (insert stubborn emoji here) 😛, word blog comes from weblog, and microblogging could derivate from 'smaller weblog'. https://www.wikiwand.com/en/articles/Microblogging

I'd differentiate it from sharing status updates as it was done with 'finger' or even a BBS. For example, being able to reply; create new threads and sharing them on a URL is something we could expect from 'Twitter', the most popular microbloging model (citation needed)

I like to discuss it, since conversations usually are improved if we sync on what we understand for the same words.

Hi everyone, I've drafted a Request for Comments (RFC) to improve how threads work in twtxt: https://git.mills.io/yarnsocial/twtxt.dev/issues/18

I’d love your feedback! Please share your thoughts on anything that could be better explained, check if the proposed dates work for everyone, and I invite you to join the discussion...

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.

Yes it work: 2024-12-01T19:38:35Z twtxt/1.2.3 (+https://eapl.mx/twtxt.txt; @eapl) :D

The .log is just a simple append each request. The idea with the .cvs is to have it tally up how many request there have been from each client as a way to avoid having the log file grow too big. And that you can open the .cvs as a spreadsheet and have an easy overview and filtering options.

Access to those files are closed to the public.

Simplified twtxt - I want to suggest some dogmas or commandments for twtxt, from where we can work our way back to how to implement different feature like replies/treads:

0. It's a text file, so you must be able to write it by hand (ie. no app logic) and read by eye. If you edit a post you change the content not the timestamp. Otherwise it will be considered a new post.

1. The order of lines in a twtxt.txt must not hold any significant. The file is a container and each line an atomic piece of information. You should be able to run sort on a twtxt.txt and it should still work.

2. Transport protocol should not matter, as long as the file served is the same. Http and https are preferred, so it is suggested that feed served via Gopher or Gemini also provide http(s).

3. Do we need more commandments?

@quark It does not. That is why I'm advocating for not using hashes for treads, but a simpler link-back scheme.

I've gathers my ideas about mentions for twtxt/yarn here: Webmentions vs. custom mentions spec for twtxt/yarn - HedgeDoc You are welcome to edit and comment in the doc, so our ideas are not fragment into a bunch of treads