Hello World! testing an offline-first PWA Yarn.social / Twtxt client :)

When the client calls to check if I got the email he sent four minutes ago ⌘ Read more

I Was Scammed Buying GLP-1s Online. I’m Not Alone
Customers have complained that a telehealth network selling compounded GLP-1s has been ripping them off—even after it had to pay $5 million to clients as part of a settlement with the US government. ⌘ Read more

When the client says “your call” and then rejects all three of my proposals ⌘ Read more

When I send “this client is so freaking annoying” to the Slack channel… the client is in ⌘ Read more

When my boss announces a feature to the client and it’s news to me ⌘ Read more

NDIS carer saves two clients from burning home
An NDIS carer has bravely risked his life to save two clients in wheelchairs from a burning home in Adelaide’s northern suburbs. ⌘ Read more

Perth house relocator leaves trail of clients, contractors claiming he owes millions
A group of aggrieved clients claim James Thomson owes them money. He claims he is the victim of an online smear campaign. ⌘ Read more

NPM packages from RedHat have been compromised
Article URL: https://github.com/RedHatInsights/javascript-clients/issues/492

Comments URL: https://news.ycombinator.com/item?id=48356625

Points: 73

# Comments: 16 ⌘ Read more

When the client signs off on my delivery on the first try ⌘ Read more

Slumber a TUI HTTP Client
Article URL: https://slumber.lucaspickering.me

Comments URL: https://news.ycombinator.com/item?id=48231938

Points: 4

# Comments: 0 ⌘ Read more

When the boss and the client kick off a fight in front of me before I’ve even had coffee ⌘ Read more

The sales rep as soon as I start talking technical in front of the client ⌘ Read more

When the lead dev personally goes to the client to fix a major bug ⌘ Read more

When the new client tells me they use a Google Sheet as a database ⌘ Read more

When the client wants the logo to be clickable “but especially without a link” ⌘ Read more

When I’m about to join a meeting with a client disputing a deliverable ⌘ Read more

When I ask the sales rep how their client meeting went ⌘ Read more

When the client says the site was actually better before after 3 months of redesign ⌘ Read more

When the client asks if we can remove the bugs but keep the features ⌘ Read more

When the client approves the quote and then negotiates after delivery ⌘ Read more

When the client thinks GDPR is just a cookie banner hardcoded on their site ⌘ Read more

When the client tells me they want an app “like TikTok” but for their industry ⌘ Read more

When the boss asks me to put on a good face with our worst client ⌘ Read more

When I have to maintain 4 versions in parallel for different clients ⌘ Read more

When the client wants a POC that’s shippable to production ⌘ Read more

When the client asks if we can have named analytics ⌘ Read more

When the client sends their specs as a PowerPoint ⌘ Read more

When the client wants a push notification for every action in their app ⌘ Read more

When the client didn’t notice the major bug during my demo and congratulates me ⌘ Read more

When the client asks me for the 6th time to change the text on their homepage ⌘ Read more

When the client who validated everything suddenly remembers a “forgotten” feature ⌘ Read more

When the sales rep comes to see me after their week of client meetings ⌘ Read more

When the sales rep overplays it in front of the client saying they’ve already coded in HTML ⌘ Read more

When the client asks if we can make their site more viral ⌘ Read more

When a client asks me for a small tweak on their legacy project ⌘ Read more

Some pretty pics to illustrate the much improved reference Salty.im client, salty-chat.

I spent the day today integrating @xuu@txt.sour.is’s double ratcheting work and ratchet library back into the reference client/broker implementation saltyim as a v2 branch. I completely redesigned and rewrite the salty-chat TUI client as well, which now includes proper notifications and a background agent that keeps running so you never miss any messages. It all “just works”™ and I’m quite happy with the outcome! 🤩 #saltyim #revamp

@klaxzy@klaxzy.net Haha, I just noticed because my client colors mentions differently depending on whether I follow the feed or not. ;-)

When the sales rep suddenly comes to grab us for a client meeting ⌘ Read more

Mais uma tentativa de golpe com mensagem fingindo ser dos Correios… fiquem muito espertos!

O domínio parece que foi registrado hoje mesmo… https://who.is/whois/encomendasnacional.org

Tem um lugar mais eficiente pra denunciar essas coisas?

https://g1.globo.com/fato-ou-fake/noticia/2025/08/18/e-fake-mensagem-de-whatsapp-que-se-passa-pelos-correios-e-cobra-taxa-para-liberar-encomenda-trata-se-de-golpe.ghtml

https://www.correios.com.br/central-de-informacoes/boletim-aos-clientes/mensagens-falsas-sobre-encomendas

#golpe #fraude

When the client sends me their list of “just 2 or 3 small things to fix” ⌘ Read more

When our biggest client praises me in front of the boss ⌘ Read more

When I hear the sales rep commit to a deadline in front of the client ⌘ Read more

When it’s the end of the year and also the end of my maintenance contract with our most annoying client ⌘ Read more

When a client demands a delivery before the end of the year ⌘ Read more

@shinyoukai@neko.laidback.moe Do we now need ad filters in twtxt clients, too? O_o I hope not! Personally, I cannot stand the “Sent with my crappy $phone/$app” e-mail footers.

But congrats on your client. :-)

When the sales guy unexpectedly pulls me into a client meeting ⌘ Read more

When I go to a client meeting while there are still several open bugs on their side ⌘ Read more

@shinyoukai@neko.laidback.moe it was a mess, we are better without it. Until a new mobile client comes (not holding my breath), Yarn is very usable on the mobile, just using the browser.

When the sales guy asks if I can quickly build an AI chat for all clients ⌘ Read more

When the boss asks me to commit to a date in front of the client ⌘ Read more

@shinyoukai@neko.laidback.moe What do you mean by that? 🧐 Clients don’t care about the order of twts in a feed. For display clients usually sort by timestamp.

When a client calls us first thing in the morning to report a bug ⌘ Read more

@shinyoukai@neko.laidback.moe I’m mostly against it because it forces Javascript™ on the client(s) at a blanket level. Doing “Proof-of-Work” explicitly IMO is fine™, but not at an Ingress/Edge level IMO – Which is why I haven’t adopted it myself.

Which actively maintained Yarn/twtxt clients are there at the moment? Client authors raise your hands! 🙋

And regarding those broken URLs: I once speculated that these bots operate on an old dataset, because I thought that my redirect rules actually were broken once and produced loops. But a) I cannot reproduce this today, and b) I cannot find anything related to that in my Git history, either. But it’s hard to tell, because I switched operating systems and webservers since then …

But the thing is that I’m seeing new URLs constructed in this pattern. So this can’t just be an old crawling dataset.

I am now wondering if those broken URLs are bot bugs as well.

They look like this (zalgo is a new project):

https://www.uninformativ.de/projects/slinp/zalgo/scksums/bevelbar/

When you request that URL, you get redirected to /git/:

$ curl -sI https://www.uninformativ.de/projects/slinp/zalgo/scksums/bevelbar/
HTTP/1.0 301 Moved Permanently
Date: Sat, 22 Nov 2025 06:13:51 GMT
Server: OpenBSD httpd
Connection: close
Content-Type: text/html
Content-Length: 510
Location: /git/

And on /git/, there are links to my repos. So if a broken client requests https://www.uninformativ.de/projects/slinp/zalgo/scksums/bevelbar/, then sees a bunch of links and simply appends them, you’ll end up with an infinite loop.

Is that what’s going on here or are my redirects actually still broken … ?

When I have to explain to the client that we can’t use their Excel 2010 file as a database ⌘ Read more

@arne@uplegger.eu @lukas@lukasthiel.de In fact, Yarn.social’s yarnd client implementation actually uses (or did, still kinda does today) PicoCSS 🤟 It was/is a good CSS library! 👍

I should work on my client again and add some new features. Like adding a new feed directly in the client and not having to go to the config first. And showing a preview of a feed before actually adding it. Also, a search would be something to add. And finally combining my User-Agent analyzer with my subscription list to spot new feeds automatically.

When the client is about to click on a button that isn’t implemented ⌘ Read more

When I show up at a new client after being sold as an expert by sales ⌘ Read more

When the client tells me I should’ve handled responsiveness even though it was never in scope ⌘ Read more

When the sales guy starts talking in a client meeting ⌘ Read more

@madcap duas perguntas:

1 você anda vendo um aviso de “demasiados pedidos” ou algo assim? Tenho visto isso no cliente Moshidon. Uma amiga minha na instância pynews.com.br também teve esse problema um tempo atrás…

2 de tempos em tempos eu esqueço como põe na interface aquela opção de posts só para a nossa instância… como faz mesmo?

When I know the client and tell the new guy to comment out code instead of deleting it ⌘ Read more

Warum erfahre ich erst im Jahr 2025 von Server-sent events (SSE) 🤔?
Das Zeug scheint für die webbasierte Server-Client-Kommunikation in JavaScript ideal zu sein und ist sehr einfach umzusetzen.

I keep getting this email occadionally:

Your iCloud storage is almost full

Now for various reasons, I don’t want my children to be using iCloud to store data, files, photos or any of the sort. They’re free to use iMessages, and other Apple services like the App Store, etc, but not storage.

So I’ve set about blocking iCloud Storage API(s) via AdGuard Home tonight as well as ensuring that my local network (client users) cannot bypass DNS policies and get out other sneaky ways, because some applications will just use other DNS servers, or DOH or DOT.

Client ID Metadata Document Adopted by the OAuth Working Group
The IETF OAuth Working Group has adopted the Client ID Metadata Document specification! ⌘ Read more

My open letter, to the European Commission digital markets act team:

Hello,

I am joining other developers, concerned about Googles new plan, to approve every app and effectively destroy most of the competing 3rd party stores this way. The biggest one of these alternative stores, most known for their focus on user and developer privacy, already states, this would make it impossible for them to operate: https://f-droid.org/cs/2025/09/29/google-developer-registration-decree.html
Even communities like the XDA forum, where new developers are often introduced to the world of Android development, would likely be strongly impacted, as making, publishing and installing Android apps is made less accessible.

I am not just writing on their behalf, I run a small website myself (https://thecanine.ueuo.com/), that both provides legal modifications, for some android apps - for example adding an amoled dark theme, to the most popular XMPP chat client for Android, or increasing one of Androids keyboard apps height. This all comes after Googles previous changes to the Android operating system, that prevent users from installing old apps (old to Google, can mean only a couple of months, without an update - https://developer.android.com/google/play/requirements/target-sdk and the target version gets increased every year). I rely on apps developed by a single developer, even for things like making the pixel art presented on my website and sideloading as a way to make these apps work, before developers can catch up to Google’s new requirements - if Google is allowed to slowly kill these options, us digital artists will soon lose the tools we need to create digital art.

nmail: Terminal-based email client for Linux and macOS
Comments ⌘ Read more

Of course, all things optional is fine. Like, it will be ignored (just like banner would) for clients having no knowledge of it.

Hello again everyone! A little update on my twtxt client.

I think it’s finally shaping a bit better now, but… ☝️

As I’m trying to put all the parts together, I decided to build multiple parallel UIs, to ensure I don’t accidentally create a structure that is more rigid than planned.

I already decided on a UI that I would want to use for myself, it would be inspired by moshidon, misskey and some other “social feeds” mock-ups I found on dribbble.

I also plan on building a raw HTML version (for anyone wanting to do a full DIY client).

I would love to get any suggestions of what you would like to see (and possibly use) as a client, by sharing a link, app/website name or even a sketch made by you on paper.

I think I’ll pick a third and maybe a fourth design to build together with the two already mentioned.

For reference, the screens I think of providing are (some might be optional or conditionally/manually hidable):

• Global / personal timeline screen
  
• Profile screen (with timeline)
  
• Thread screen
  
• Notifications screen or popup (both valid)
  
• DM list & chat screens (still planning, might come later)
  
• Settings screen (it’ll probably be a hard coded form, but better mention it)
  
• Publish / edit post screen or popup (still analysing some use cases, as some “engines” might not have direct publishing support)
  

I also plan on adding two optional metadata fields:

• display_name: To show a human readable alternative for a nick, it fallback to nick if not defined
  
• banner: Using the same format as avatar but the image expected is wider, inspired by other socials around
  

I also plan on supporting any metadata provided, including a dynamically parsable regex rule format for those extra fields, this should allow anyone to build new clients that don’t limit themselves to just the social aspect of twtxt, hoping to see unique ways of using twtxt! 🤞

@zvava@twtxt.net

(#abcdefghijkl https://example.com/tw.txt#:~:text=2025-10-01T10:28:00Z), because it can be simply hacked in to clients currently on hashv1 and provides an off-ramp to location-based addressing

I like that property (an off-ramp to location-based addressing), so I think I could live with that approach. ✅

(I’m not sure why we’re using text fragments, though. Wouldn’t that link to the first occurence of 2025-10-01T10:28:00Z? That’s not necessarily correct. And, to be proper URLs that Firefox and Chromium understand, it would also need to be written as 2025%2D10%2D01T10:28:00Z. The dash carries meaning, sadly. I think all this just creates needless complication. How about we just go with https://example.com/tw.txt#2025-10-01T10:28:00Z?)

@zvava@twtxt.net My clients trusts the first url field it finds. If there is none, it uses the URL that I’m using for fetching the feed.

No validation, no logging.

In practice, I’ve not seen issues with people messing with this field. (What I do see, of course, is broken threads when people do legitimate edits that change the hash.)

I don’t see a way how anyone can impersonate anybody else this way. 🤔 Sure, you could use my URL in your url field, but then what? You will still show up as zvava in my client or, if you also change your nick field, as movq (zvava).

@alexonit@twtxt.alessandrocutolo.it prologic has me sold on the idea of hashv2 being served alongside a text fragment, eg. (#abcdefghijkl https://example.com/tw.txt#:~:text=2025-10-01T10:28:00Z), because it can be simply hacked in to clients currently on hashv1 and provides an off-ramp to location-based addressing (though i still think the format should be changed to smth like #<abc... http://example.com/...> so it’s cleaner once we finally drop hashes)

Great to see so many new clients popping up. 👌

Hi everyone, here’s a little introduction of my twtxt client (still WIP).

The client I’m developing is a single tenant project that runs entirely in the browser (it might use an optional backend).

It’s entirely based on native web-components and vanilla JS, it is designed to act closer to a toolkit than a full-fledged client, allowing users to “DIY” their own interface with pure html or plain javascript functions.

Users can also build their own engines by including a global javascript object that implement the defined internal API (TBD).

I’m planning to build a system that is easy enough to build and use with any skill level, using only pure html (with a homebrew minimal template engine) or via plain JS (I’ll be also providing some pre-made templates too).

Everything can be self-hosted on any static hosting provider, this allows to spread twtxt within communities like Neocities and similarly hosted websites (basically any Indieweb/Smallweb/Digital garden website and any of the common GitHub/Lab/Berg/lify Pages).

It will be probably named something like TxtCraft or craf.txt but I’m not really sure yet… 🤔 (Maybe some suggestions could help)

I’m still in the experimental phase, so there’s no decent source-code to share yet, but it will soon enough!

Exactly, @zvava@twtxt.net, I agree. (Although, in my client at least, I wouldn’t use hashes anywhere.)

That’s what I’m using right now, while my own client is still in the making.

A simple bash script to write a post in a mktemp file then clean it with regex.
I don’t even bother to hash the replies, I just open https://twtxt.net and copy the hash by hand since I’m checking the new posts from there anyway (temporarily, as I might end up DoS-ing everyone’s feed in my client right now).

plus, if hashv2 was implemented in combination with text fragments the way you proposed that would solve both scripting and human readability woes!!

…though, the presence of the text fragments then makes reversing the replied-to twt (and therefore its hash) trivial, which could allow clients to tolerate the omission of the hash — and while it would be ‘non-standard’ this would be the best of both worlds; potential to tolerate (or pave a glacial path toward? :o) human writable replies whilst keeping a unique id for twts that is universal across all pods

Put another way, what you are proposing/pushing for requires hundreds of lines of code to change across a half dozen or so clients and lots of breaking changes, not to mention unknowns.

What I want us to do is make only a few half dozen or so lines of code changes to our clients and minimize the breaking changes and unknowns.

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

@prologic@twtxt.net the simplest thing to do is to completely forgo hashing anything because we are communicating using plain text files right now :3 while i agree hashes are incredibly helpful in the backend im not sure it has a place outside of it, it basically eliminates two core design principals of twtxt (human readability and integrating well with unix command line utilities) and makes new clients more difficult to build than it should be

@prologic@twtxt.net considering other alternatives we have seeing (of which I have lost track already), yes. Why don’t you guys (client makers) take a step at a time and, for now, increase the hash length to deal with the collisions. Then location-based addressing can be added… or not, you know. 😅

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.
  

…

@prologic@twtxt.net I know we won’t ever convince each other of the other’s favorite addressing scheme. :-D But I wanna address (haha) your concerns:

1. I don’t see any difference between the two schemes regarding link rot and migration. If the URL changes, both approaches are equally terrible as the feed URL is part of the hashed value and reference of some sort in the location-based scheme. It doesn’t matter.

2. The same is true for duplication and forks. Even today, the “cannonical URL” has to be chosen to build the hash. That’s exactly the same with location-based addressing. Why would a mirror only duplicate stuff with location- but not content-based addressing? I really fail to see that. Also, who is using mirrors or relays anyway? I don’t know of any such software to be honest.

3. If there is a spam feed, I just unfollow it. Done. Not a concern for me at all. Not the slightest bit. And the byte verification is THE source of all broken threads when the conversation start is edited. Yes, this can be viewed as a feature, but how many times was it actually a feature and not more behaving as an anti-feature in terms of user experience?

4. I don’t get your argument. If the feed in question is offline, one can simply look in local caches and see if there is a message at that particular time, just like looking up a hash. Where’s the difference? Except that the lookup key is longer or compound or whatever depending on the cache format.

5. Even a new hashing algorithm requires work on clients etc. It’s not that you get some backwards-compatibility for free. It just cannot be backwards-compatible in my opinion, no matter which approach we take. That’s why I believe some magic time for the switch causes the least amount of trouble. You leave the old world untouched and working.

If these are general concerns, I’m completely with you. But I don’t think that they only apply to location-based addressing. That’s how I interpreted your message. I could be wrong. Happy to read your explanations. :-)

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.

@zvava@twtxt.net @lyse@lyse.isobeef.org I also think a location based reference might be better.

A thread is a single post of a single feed as a root, but the hash has the drawback of not referencing the source, in a distributed network like twtxt it might leave some people out of the whole conversation.

I suggest a simpler format, something like: (#<TIMESTAMP URL>)

This solves three issues:

• Easier referencing: no need to generate a hash, just copy the timestamp and url, it’s also simpler to implement in a client without the rish of collisions when putting things together
  
• Fetchable source: you can find the source within the reference and construct the thread from there
  
• Allow editing: If a post is modified the hash becomes invalid since it depends on [ timestamp, url, content ]

Hello everyone! 👋

After a long while away, I’m back on twtxt with this new feed.

Some of you might remember me as justamoment@twtxt.net, that was a test account I made for trying things out, but I ended up keeping it more than planned.

I also tried other social platforms in search of a place that felt right for me.

In the end twtxt was the one that ticked all of my boxes:

• Slow social: it act more like a feed reader and I really appreciate that there’s no flood of content that I can’t keep up with.
  
• No server needed: I absolutely love to have total control over my content, I tend to avoid having moving parts that might break, plus you can put your feed under version control and it’s all backed up.
  
• Ownership: I can put my feed anywhere I want and nobody can decide if I can access it or not.
  
• For hackers: a single .txt file allows me to join a community, how cool is that!
  

This is why I decided to build my own twtxt client, one that allows you to decide how the feed is presented on your “instance”.

It’s still in the making but I’ll try to share a bit of it once I defined how things should work.

Coincidentally, I discovered that @itsericwoodward@itsericwoodward.com and @zvava@twtxt.net were also building a twtxt client, seems like twtxt is set to grow!

@sysop ao tentar ir a https://ciberlandia.pt/conversations levo com isto:

ReferenceError: account is not defined
U= (https://ciberlandia.pt/packs/direct_timeline-index-CclzgTb8.js:1:5335)
ie (https://ciberlandia.pt/packs/logo-CwPlYIww.js:15:35348)
ie (https://ciberlandia.pt/packs/logo-CwPlYIww.js:15:25299)
ie (https://ciberlandia.pt/packs/logo-CwPlYIww.js:15:35287)
U= (https://ciberlandia.pt/packs/direct_timeline-index-CclzgTb8.js:1:5304)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:61330)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:116588)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:112269)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:112197)
Ff (https://ciberlandia.pt/packs/client-DZIGVCsa.js:33:112051)

@zvava@twtxt.net Good question. This is the spec, I think:

https://twtxt.dev/exts/metadata.html#nick

It doesn’t say much. 🤔

In the wild, I’ve only seen “traditional” nick names, i.e. ASCII 0x21 thru 0x7E.

My client removes anything but r'[a-zA-Z0-9]' from nick names.

@zvava@twtxt.net There would be only one hash for a message. Some to be defined magic date selects which hash to use. If the message creation timestamp is before this epoch, hash it with v1, otherwise hammer it through v2. Eventually, support for v1 could be dropped as nobody interacts with the old stuff anymore. But I’d keep it around in my client, because why not.

If users choose a client which supports the extensions, they don’t have to mess around with v1 and v2 hashing, just like today.

As for the school of thought, personally, I’d prefer something else, too. I’m in camp location-based addressing, or whatever it is called. There more I think about it, a complete redesign of twtxt and its extensions would be necessary in my opinion. Retrofitting has its limits. Of course, this is much more work, though.

@zvava@twtxt.net And yes yarnd does have a well documented API and two clients (CLI and unmaintained Flutter App)

@bender@twtxt.net @thecanine@twtxt.net well now this has me thinking abt the feasibility of making an android twtxt app for pods, the actual apis of pods would have to be standardized (or the fucked up way that activitypub does it, where the “mastodon api” is the defacto client api (does yarn even have an api reference?)) or the client is just simply..a client..but editing feeds via PUT, PATCH, DELETE etc. is standardized!…? (not to mention i dont even know where to begin making an android app lmao)

Wanting to add, this isn’t a twtxt client. It is Yarnd on steroids! 😂

@kat@yarn.girlonthemoon.xyz I reckon the original <details> need to have the open attribute set in order to expand it, so I cannot just define some custom CSS rules to do that in my browser.

But in regards to twtxt, my client won’t hide anything in that realm anyway. :-) It’s just more noise.

JMP: Newsletter: (e)SIM nicknames, Cheogram Android updates, and Cheogram iOS alpha
Hi everyone!

Welcome to the latest edition of your pseudo-monthly JMP update! (it’s been 7 months since the last one 😨)

In case it’s been a while since you checked out JMP, here’s a refresher: JMP lets you send and receive text and picture messages (and calls) through a real phone number right from your computer, tablet, phone, or anything else that has a Jabber client. Among other things, JMP has these features: Y … ⌘ Read more

What kind of client for linux do I need?

i know yarn has a CLI client in yarnc but ngl i wish there was a TUI client. that’d be really fun