@rdlmda@rdlmda.me You need to use the RFC3339 format. I would recommend you read the specs at https://twtxt.dev – This is what is used by many moden clients these days 😅

👋 Looking for other interested folks to continue to evolve the development of Salty.im 🙏 I’ve been hard™ at work on the v2 branch and @doesnm.p.psf.lt@doesnm.p.psf.lt has been incredibly helpful so far. Be great ot have a few more folks to join us, some of the v2 highlights include:

• Double Ratchet by default.
  
• Group Chat (sender/client fan-out for now)
  
• Much better TUI with background agent.
  
• Mobile App coming soon™ (iOS in progress, Android next, same codebase)

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. ;-)

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

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

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

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

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

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.

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.

@zvava@twtxt.net @bender@twtxt.net At first I added it without thinking when planning the possible fields based on other UIs I was researching.

I was about to discard it but after thinking about it a bit I noticed that the services allowing to have a separated nick and display_name could unlock some good uses.

For example some added context or at-a-glance information like pronouns or statuses (like Artist [Accepting commissions] or App Name (v2.5)) while other used a more readable version of the nick (blog.domain.com became Person Name's Blog).

Of course it is absolutely optional and it can be safely ignored, but with my vision of being able to build more that a pure twtxt clients, giving it a first-class support just like the other known fields felt right to me.

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! 🤞

@bender@twtxt.net The first format use the subject extension while the other is a new format that is inspired by mentions format, the first one should be compatible but I’m not sure, if it’s used verbatim by the client it would work, but if we consider the new proposal for it to have an optional part it wont work on clients without changes.

@lyse@lyse.isobeef.org I think will be bad if handled incorrectly.

The client must reference both properly or it would miss posts, including both this way is a bit pointless if you can’t use the hash or url separately.

Being a highly likely a breaking change anyway I think @zvava@twtxt.net proposal looks much better.

@lyse@lyse.isobeef.org i would like to ditch hash addressing but as was pointed out it would be a pain in the ass to get clients currently working off of hashv1 to suddenly switch to location-based addressing instead of just hashv2 with the option to eventually phase it out — unless we can rally together all active client developers to decide on a location-based addressing specification (i still think my original suggestion of #<https://example.com/tw.txt#yyyy-mm-ddThh:mm:ssZ> is foolproof)

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

@zvava@twtxt.net That was my greatest concern with how it is currently handled, I’m afraid to break threads even by fixing a typo.

Handling it via the pod might work but I think it’s not the best approach, external feeds and clients don’t usually use a pod api but their own implementation, so any workaround won’t work there.

That’s why my proposals addressed those issues:

• the idea of using a “key” instead of the url (with the url as a fallback), the key could even be a public key so it can be used verifieable in crypto functions
  
• using the timestamp to prevent content changes to break threads (plus being simpler to implement)
  
• using an explicit thread reference with an alternative subject format (like [#THREAD_ID] Hello world and replies with (#REPLY_ID) Ahoy) so the content can change without affecting the thread reference, and anyone can use their own schemes freely

@zvava@twtxt.net I’m not sure, I could just set up a cors-anywhere via docker in a minute and it would work the same.

Still, I could write one with just a dozen lines of Go or Node.js, I might consider writing one after the client is working decently.

I tried enabling nginx gzip and i was wondering why it always sent gzip compressed data, even when the client doesn’t support it. Then i realized that i accidentally replaced the original file iwth the compressed one. Whoops!

@zvava@twtxt.net What is a nice twtxt client to use?

@zvava@twtxt.net CORS is our worst enemy. 🥷

I too had the same issue being a browser-based request, so the only solution is using a proxy.

For testing (and real personal use) I rely on this one https://corsproxy.io/.

In my client, I first check if the source allows me to fetch it without issues first and fallback to prefixing with a proxy if it gives an error.

For security reasons the client don’t give you a readable error for CORS, so you must use a catch-all for that, if it fails again with the proxy you can deal with any other errors it throws as you normally would (preferably outside of the fetch function).

After the fetching responded, I store the response.url value to fetch it again for updates without having to do extra calls (you can store it verbatim or as a flag to be able to change the proxy later).

Here an extract of my code:

export async function fetchWithProxy(url, proxy=null) {
    return await fetch(url).catch(err => {
        if (!proxy) throw err;
        return fetch(`${proxy}${encodeURIComponent(url)}`);
    });
}

// Using it with
const res = await fetchWithProxy('https://twtxt.net/user/zvava/twtxt.txt', 'https://corsproxy.io/?');

// Get the working url (direct or through proxy)
const fetchingURL = res.url;

// Get the twtxt feed content (or handle errors)
const text = await res.text();

I also plan to allow the user to define a custom proxy field, I like the solution used by Delta.chat in their android app, where you can define the URL format with a variable https://my-proxy?$TWTXT_URL since it allows you to define with more freedom any proxy without a prefix format.

If the idea of using a third-party proxy is not to the user liking they can use a self-hosted solution like cors-anywhere or build their own (with twtxt it should just be a GET).

Great to see so many new clients popping up. 👌

@bender@twtxt.net Yes and no.

To build a compliant PWA you need to provide a webmanifest json and a service worker.

Those requirements are not directly part of this project.

You can build the client as a standalone PWA or even as a widget inside an existing page.

The general steps are closer to how you would include a third-party library in an existing project, by importing it as a dependency and using it in your website.

I’m pretty sure most users would expect a PWA (me included) so I plan to provide a ready-made template ready to be deployed as is.

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!

@lyse@lyse.isobeef.org Thanks!

The way I have it setup right now would take me more work to integrate with your script though.

I’m keeping things dumb on purpose, I just have to finish my client to have all the cool buttons that do it for me.

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

@prologic@twtxt.net Well, personally I would, as I already do for user feeds in my client.

That’s why part of my proposal was to allow custom strings and be free from a specific format that need periodical upgrades, but it’s not much of a problem in the end.

I’ll adapt to what we can get out of this.

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 twts whilst keeping a unique id for twts that is universal across all pods

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

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

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.
  

…

@lyse@lyse.isobeef.org @prologic@twtxt.net Can’t we find a middle ground and support both?

The thread is defined by two parts:

1. The hash
   
2. The subject
   

The client/pod generate the hash and index it in it’s database/cache, then it simply query the subject of other posts to find the related posts, right?

In my own client current implementation (using hashes), the only calculation is in the hash generation, the rest is a verbatim copy of the subject (minus the # character), if this is the common implemented approach then adding the location based one is somewhat simple.

function setPostIndex(post) {
    // Current hash approach
    const hash = createHash(post.url, post.timestamp, post.content);

    // New location approach
    const location = post.url + '#' + post.timestamp;

    // Unchanged (probably)
    const subject = post.subject;

    // Index them all
    addToIndex(hash, post);
    addToIndex(location, post);
    addToIndex(subject, post);
}

// Both should work if the index contains both versions
getThreadBySubject('#abcdef') => [post1, post2, post3]; // Hash
getThreadBySubject('https://example.com#2025-01-01T12:00:00') => [post1, post2, post3]; // Location

As I said before, the mention is already location based @<example https://example.com/twtxt.txt>, so I think we should keep that in consideration.

Of course this will lead to a bit of fragmentation (without merging the two) but I think this can make everyone happy.

Otherwise, the only other solution I can think of is a different approach where the value doesn’t matter, allowing to use anything as a reference (hash, location, git commit) for greater flexibility and freedom of implementation (this probably need the use of a fixed “header” for each post, but it can be seen as a separate extension).

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

@prologic@twtxt.net I can see the issues mentioned, but I think some can be fixed.

1. The current hash relies on a url field too, by specification, it will use the first # url = <URL> in the feed’s metadata if present, that too can be different from the fetching source, if that field changes it would break the existing hashes too, a better solution would be to use a non-URL key like # feed_id = <UNIQUE_RANDOM_STRING> with the url as fallback.

2. We can prevent duplications if the reference uses that same url field too or the client “collapse” any reference of all the urls defined in the metadata.

3. I agree that hashing based on content is good, but we still use the URL as part of the hashing, which is just a field in the feed, easily replicable by a bot, also noting that edits can also break the hash, for this issue an alternative solution (E.g. a private key not included in the feed) should be considered.

4. For offline reading the source would be downloaded already, the fetching of non followed feeds would fill the gap in the same way mentions does, maybe I’m missing some context on this one.

5. To prevent collisions there was a discussion on extending the hash (forgot if that was already fixed or not), but without a fallback that would break existing clients too, we should think of a parallel format that maintains current implementations unchanged, we are already backward compatible with the original that don’t use threads at all, a mention style format for that could be even more user-friendly for those clients.

We should also keep in mind that the current mention format is already location based (@<example https://example.com/twtxt.txt>) so I’m not that worried about threads working the same way.

Hope to see some other thought about this matter. 🤓

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.

While working on the Discoverability for my twtxt client (it runs client-side) I found out that Chrome doesn’t allow to set a custom user agent. 🙃

I thought it was a general thing for browsers, but it that was actually allowed in a newer specification, yet it’s still not implemented in Chrome, it does work in Firefox though.

@thecanine@twtxt.net With a progressive web app (PWA) you can have a native like experience without having to trouble yourself with building a second project that act as a client.

You can even “wrap” it into a packaged installation and publish it on stores, theres even projects to streamline it https://www.pwabuilder.com/.