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

on timeline the mention looks OK. Is there an issue on Yarn?

It's an interesting topic. For example on Bsky it's natural to allow domains https://bsky.social/about/blog/4-28-2023-domain-handle-tutorial

Although TwiXter only allows (letters A-Z, numbers 0-9 and of underscores) https://help.x.com/en/managing-your-account/x-username-rules

it should be `# 2025-04-13T11:02:12+02:00

my main itch with the DMs extensions is that these messages are intended to be private, not public information. That's why other extensions make sense, but DMs are another kind of feature. TwiXter, Mastodon, FB and some other services usually hide the DMs in another section, so they are not mixed with the public timeline.

I find the DM topic interesting, I even made an indie experiment for a centralized messaging system here https://github.com/eapl-gemugami/owl. Although, as I've said a few times here, I'm not particularly interested in supporting it on microblogging, as I don't use it that much. In the rare case I've used them, I don't have to manage public and private keys, and finally none of my acquaintances use encrypted email. Nothing personal against anyone, and although I like to debate and even fight, it's not the case here. This proposal is the only one allowing DMs on twtxt, and if the community wants it, I'll support it, with my personal input, of course.

A good approach I could find with a good compromise between compatibility with current clients and keeping these messages private is 'hiding' the DMs in comments. For example: `# 2025-04-13T11:02:12+02:00

In Mexico you couldn't register the word Sonora (state), nor Taqueria (kind of restaurant) as there are two common words, but perhaps the combination of both is trademarkable, I'm not sure, so many 'taquerias' here don't file a trademark request. It's usually "Taquería [LAST_NAME]" or "Taquería [PLACE]".

At the same time, the word "taqueria" was trademarked in UK, like it would be "Paris" or "Pub" I guess, so basically Sonora Taqueria didn't reply to the cease and desist, based on:

[Lizbeth García]: A brand may not use a word that is generic or descriptive of the products or services it is putting into circulation on the market.

Since he (Ismael, Taqueria's representative) didn’t get any response, he decided to leave it in the hands of his law firm.

In early 2023, after all the noise on the internet and the mobilization caused by this case, an agreement was finally reached with Taquería to settle the matter peaceably.

In March 2023, Michelle and Sam decided to register the Sonora Taquería brand and logo with the UK Intellectual Property Office.

well, I assume by syntax you mean Gemtext (which I like a lot, my personal blog is built on top of it), so I think it might work for twtxt clients...

I knew of twtxt in Gemini Antenna, so at least the 2017 spec might work on that protocol. I think the main issue with extensions is that they weren't designed with many URLs and protocols in mind.

Also I have to admit that the Gemini community significantly reduced in the last few years. I don't know how worth it is to add support for Gemini now.

do you mind sharing a picture ?

I can't find something similar here, but my wife gave this one last year, and I've been using it a bit. I'd say it's useful as you've shared.

We also have a shared calendar in the kitchen for family events, and it's working great.

pls elaborate on a 'p2p database', 'all story' and 'Registries'.

My first thought takes me to something like secure-scuttlebutt which it's painful to sync data using clients, and too slow compared to downloading a text file.

Also I'd like for twtxt to avoid becoming an ActivityPub. Works well but it's uses too many resources IMO. https://kingant.net/2025/02/mastodon-the-cost-of-running-my-own-server/

I'm defending being able to self-host your Web client (like you'd do with a Wordpress, twtxt is a micrologging, at the end), instead of federated instances, so in a first thought I'd say Registries have many disadvantages being the first one that someone has to maintain them active.

I like this syntax, you have my vote, although I'd change it a bit like #<Alice https://example.com/twtxt.com#2024-12-18T14:18:26+01:00>

Hashes are not a problem on PHP, I dont know why it's slow to calculate them from your side, but I agree with your points.

BTW, did you have the chance to read my proposal on twtxt 2.0? I shared a few ideas about possible improvements to discuss: https://text.eapl.mx/a-few-ideas-for-a-next-twtxt-version https://text.eapl.mx/reply-to-lyse-about-twtxt

trying to implement it quickly, I get the same questions than you

# https://www.php.net/manual/en/function.openssl-pbkdf2.php
    $password = $sharedKey;
    $salt = openssl_random_pseudo_bytes(16);  # What's the salt length ?
    $keyLength = 20;  # What's the key length here ?
    $iterations = 100000;
    $generatedKey = openssl_pbkdf2($password, $salt, $keyLength, $iterations, 'sha256');
    echo bin2hex($generatedKey)."\n";
    echo base64_encode($generatedKey)."\n";

    $iv = openssl_random_pseudo_bytes(16); // AES-256-CBC requires 16-byte IV
    $cipherText = openssl_encrypt($message, 'aes-256-cbc', $generatedKey, OPENSSL_RAW_DATA, $iv);
    return base64_encode($iv . $cipherText);

that's a fair point.

Perhaps, since Twitter in 2006 never implemented read flags, every derivative microblogging system never saw that as an expected feature. This is curious because Twitter started with SMS, where on our phones we can mark messages as read or unread. I think it all comes from the difference between reading an email (directed to you) vs. reading public posts (like a blog or a 'wall,' where you don't mark posts as read). It's not necessary to mark it as 'read', you just jump over it.

Reading microblogging posts in an email program is not common, I think, and I haven't really used it, so I cannot say how it works, and whether it would be better for me or not. However, I've used Thunderbird as a feed reader, and I understand the advantages when reading blog posts.

About read flags being simple, well... we just had a discussion this morning about how tracking read messages would require a lot of rethinking for clients such as timeline where no state is stored. Even considering some kind of 'notification of unread messages or mentions' is not expected for those minimalist client, so it's an interesting compromise to think about.

another one would be to allow changing public keys over time (as it may be a good practice [0]). A syntax like the following could help to know what public key you used to encrypt the message, and which private key the client should use to decrypt it:

!<nick url> <encrypted_message> <public_key_hash_7_chars>

Also I'd remove support for storing the message as hex, only allowing base64 (more compact, aiming for a minimalistic spec, etc.)

[0] https://www.brandonchecketts.com/archives/its-2023-you-should-be-using-an-ed25519-ssh-key-and-other-current-best-practices

after thinking and researching about it, yep, I agree that WebFinger is a good idea.

For example reading here: https://bsky.social/about/blog/4-28-2023-domain-handle-tutorial I wasn't considering some scenarios, like multiple accounts for a single domain (See 'How can I set and manage multiple subdomain handles?' in the link above)