Timeline Sandbox

@eapl.me

Human Level 37, Engineer 🔧, scientist 🔬 y co-creator of organizations 🌱, living in Mexico 🌎, and working with people across the world 🗺️ y, learning to enjoy life! Texts and links on https://eapl.me

@eapl.me

that said, and reading to @sorenpeter and @andros I have new thoughts. I assume that this won't change anyone's opinions or priorities, so it makes no harm sharing them.

It's always tempting to use something that already exists (like X, Masto, Bsky, etc.) rather that building anything through effort and disagreement until reaching to something useful and valuable together. A 'social service' is only useful if people is using it.

I'll add that I haven't lost interest on the 'hacky' part of twtxt about developing tools, protocols, and extensions as a community. It's the appealing part! It's a nice hobby to have, shared with random people across the world. But this is not the right way for me, and makes me feel that I'm unwelcome to propose something different (after watching replies to my previous twt). Feels like "If you don't agree, you are free to leave, we'll miss you." Naah, not cool. I've lived that many times before, and nowadays I don't have enough spare time and energy for a hobby like that.

Let's see what happens next with the micro-community!

In reply to: #ceripcq 11 months ago
@eapl.me

just for the record I didn't say I was leaving the twtxt 'community' (did I?) but than I have other priorities to focus on in the following months. Please don't be condescending, is not cool.

Development of Timeline (PHP client) has been stale for some reasons, a few of them in my side, so I think it won't be updated to the new thread model, at least pretty soon. So is not that I'll stop using twtxt, just the client I use won't be compatible with the new model in July.

In reply to: #ceripcq 11 months ago
@eapl.me

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

In reply to: #ceripcq 11 months ago
@eapl.me

hehe, just catching up on this thread! I've replied in another that using periods/dots sounds good to me as it's usual in domains, but perhaps some agreement would be needed. For now I think any character is valid as long as it is not a space. For example we are using this for PHP twtxt.php#L153

In reply to: #z4hlt4a 11 months ago
@eapl.me

ok! sorry, somehow I'm getting lost in the replies.

In reply to: #7dl5bsq 11 months ago
@eapl.me

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

In reply to: #7dl5bsq 11 months ago
@eapl.me

by commenting out DMs are you giving up on simplicity? See the Metadata extension holding the data inside comments, as the client doesn't need to show it inside the timeline.

I don't think that commenting out DMs as we are doing for metadata is giving up on simplicity (it's a feature already), and it helps to hide unwanted DMs to clients that will take months to add it's support to something named... an extension.

For some other extensions in https://twtxt.dev/extensions.html (for example the reply-to hash <a href="?search=abcdfeg" class="tag">#abcdfeg</a> or the mention @ < example http://example.org/twtxt.txt >) is not a big deal. The twt is still understandable in plain text. For DM, it's only interesting for you if you are the recipient, otherwise you see an scrambled message like 1234567890abcdef=. Even if you see it, you'll need some decryption to read it. I've said before that DMs shouldn't be in the same section that the timeline as it's confusing.

So my point stands, and as I've said before, we are discussing it as a community, so let's see what other maintainers add to the convo.

In reply to: #vleuoyq 11 months ago
@eapl.me

@andros I give you not creating another file, but then I'd vote for commenting out DMs. See https://eapl.me/timeline/post/z5e2bna

It's easier to find the DM in comments from your side, than asking all the client maintainers to add the regex =P You can even use a Modified comment, such as #! <DM content> Or something like that

This approach is retro-compatible with current and older clients.

In reply to: #vleuoyq 11 months ago
@eapl.me

just a note that we are doing that on PHP: https://github.com/eapl-gemugami/twtxt-php/blob/master/docs/03-hash-extension.md#php-72

That PHP snippet could be merged into https://twtxt.dev/exts/twt-hash.html

In reply to: #euoos2q 11 months ago
@eapl.me

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

In reply to: #2zhuzoa 11 months ago
@eapl.me

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 reply to: #2zhuzoa 11 months ago
@eapl.me

I think that having a dm-only.txt, twtxt-dm.txt or any other name for an alternative file is the most sensible approach. The name could be specified in the metadata.

In reply to: #zwr3hiq 11 months ago
@eapl.me

not a big deal as I can skip those messages, but again, it's an extension, so older clients shouldn't be affected by a new feature.

In reply to: #mfygfma 11 months ago
@eapl.me

I'm also thinking that some kind of tag might be needed to automatically hide twts from unknown extensions. For example our client doesn't support DMs and always shows the !<nick url><encrypted_message> syntax which is meaningless.

In reply to: #mfygfma 11 months ago
@eapl.me

well, I suggested that in https://eapl.me/timeline/conv/k2ob6bq

The idea was to help those following the spec in https://twtxt.dev/exts/directmessage.Html, to replicate the steps and validate whether your implementation gives the same result.

BTW, you could add a link to the spec in the echo web.

In reply to: #mfygfma 11 months ago
@eapl.me

you got me 😜, it was like a few Internet centuries ago

In reply to: #52haala 11 months ago
@eapl.me

the Fireworks and Confetti animations are amazing. It reminds me a lot of my first code on QBasic a few years ago.

In reply to: #3myla6q 11 months ago
@eapl.me

yep, it looks nice! How could add my URL? Is it following the same endpoints than https://registry.twtxt.org/swagger-ui/#/users/addUser ?

BTW, I think that the usage section has a wrong base URL or something.

For example if you enter here: https://watcher.sour.is/conv/4rx5iyq It says to look for this URL: https://watcher.sour.is/conv/4rx5iyq/api/plain/users

Which seems to return the content from https://watcher.sour.is

In reply to: #d3sbkoq 1 year ago
@eapl.me

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.

In reply to: #j6oqhoa 1 year ago
@eapl.me In reply to: #lwctdja 1 year ago
@eapl.me

well, there is a whole book about piracy, DRM and selling stuff on the internet. https://en.m.wikipedia.org/wiki/Information_Doesn%27t_Want_to_Be_Free

So I won't add much to the topic, what I can say is that this is about being pragmatic. There is some people who's gonna spend their money on books but it requires publicity (polemic topic) and subsidizing creativity with our own money (another controversial one).

Otherwise it's a difficult discipline /profession /industry

In reply to: #cs6lodq 1 year ago
@eapl.me

yay! A new client 😀

In reply to: #lwctdja 1 year ago
@eapl.me

definitely 1e100 superiorer

Now I'm looking forward to see the next version using MessagePack

In reply to: #ywytxua 1 year ago
@eapl.me

that's certainty an interesting idea.

Building on top of that, I'm thinking of https://eapl.me/yatwt.yaml

In reply to: #afmdzca 1 year ago
@eapl.me

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

In reply to: #cs6lodq 1 year ago
@eapl.me

nice!

In reply to: #afmdzca 1 year ago
@eapl.me

thanks for sharing @xuu!

Checking for example https://watcher.sour.is/api/plain/twt or https://registry.twtxt.org/api/plain/tweets, I don't know whether this syntax is being used by clients or by people. Is it integrated on Yarn in any way? Genuinely asking to know more about it.

If I might throw a quick thought to those working on the registries, it would be nice to have an endpoint with a valid twtxt output (perhaps cached or dumped to a static file) which a client could point to, helping to discover it's content in a way which is compatible with the twtxt spec.

Taking the first twt I found in https://watcher.sour.is/api/plain/twt as an example: `reddit_world_news

In reply to: #gyneajq 1 year ago
@eapl.me

sorry @prologic, timeline doesn't autocomplete the mentions yet, and it was 'difficult' to look for your URL from the phone.

In reply to: #lnrgahq 1 year ago
@eapl.me

somehow I forgot that existed.

Perhaps it was its mention of being a demo implementation here: https://twtxt.readthedocs.io/en/latest/user/registry.html#registry So I though it wasn't really active.

Anyway, I think that's a good idea.

Is there something similar available on Yarn? Sorry for for asking if that was mentioned recently.

I think that the clients may help you to submit your URL to these directories, and also to get a view of the twts in them.

In reply to: #gyneajq 1 year ago
@eapl.me

thanks @prologic! @bender the idea of the RFC was to reach an agreement on a difficult problem, receiving proposals, and the voting is a simple count to gauge the sentiment of "is this a problem worth to be fixed?, are we committed to implement a change in our clients?"

But that's a fair point. What do the community expect? What do y'all expect?

In reply to: #4xaabhq 1 year ago
@eapl.me

thanks? 😆

Now I need the non-hacker friends 🥲

In reply to: #7xubh7a 1 year ago
@eapl.me

it seems I don't know how to do Markdown 😅

In reply to: #7xubh7a 1 year ago
@eapl.me

Twtxt was made for nerds, by nerds. I'd like to change that. It's by nerds/hackers, for nerds/hackers and friends of these. It doesn't have to be hacky all the time, as you don't need to be a nerd to have a blog. But, for that to happen, someone has to build the tools to improve UX.

by design there really is no way to easily discovers others Yeah, I agree, and although there are directories of email addresses, usually you don't want that, unless you are a 'public figure'. I couldn't say that a microblogging is a "social network" by default, as a blog is not either. At the same time, people would expect to find new people and conversations, as you'd do in a forum.

I think of two features on top of the current spec:

  • Clients showing a few posts of what your following are watching but you don't, so perhaps you find something interesting to follow next. Or that feature of "Your 'followings' are following these accounts/people". (Hard to explain in english, but I hope you get the idea)
  • Sharing your .txt into some directory, saying "Hey, I have this twtxt URL, I want to be discovered". I'm thinking of something like the Federated tab on Mastodon.
In reply to: #7xubh7a 1 year ago
@eapl.me

thanks andros!

instead of adding the new twt at the end of the feed, do it at the beginning The PHP client did that originally, although I didn't see a real benefit if you use... a client. It could help if you read the .txt file through a browser or something. Also, not many clients are prepared to cut the request, and you can't rely on the file being organized that way, so finally we dropped that feature.

In reply to: #lshczrq 1 year ago
@eapl.me

2 is a great idea, you should suggest it in that blog post.

About 1, well, I think anyone has an email address and only about 5% use a Feed, so it makes sense to offer what most people use 🤔

In reply to: #4jiragq 1 year ago
@eapl.me

yeah, that's the tricky part of adding features

In reply to: #ajd3rxa 1 year ago
@eapl.me

"it is very easy to filter or ignore it" This is the interesting part for legacy clients, hehe

Joking aside, let's see how it works in the wild!

In reply to: #xxu5i3a 1 year ago
@eapl.me

I have finished 1-9 on Python. If anyone is interested, I could share the code, or in Reddit many people have shared theirs.

In reply to: #tx6ja2q 1 year ago
@eapl.me

👀

Is it working now? I'd say again that perhaps the DMs could be stored in another .txt, but anyway I'd like to try it.

In reply to: #xxu5i3a 1 year ago
@eapl.me

I don't have the need for a physical Calc nor a watch, although I'm slightly more interested in a https://banglejs.com or an eink watch 🤔

In reply to: #uuch2uq 1 year ago
@eapl.me

yeah, it worked, thanks! :)

In reply to: #egeuq2q 1 year ago
@eapl.me

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.

In reply to: #6kqvwyq 1 year ago
@eapl.me

also I've made a draft of a voting page to receive preferences on each proposal https://eapl.me/rfc0001/

Help me to play with it a bit and report any vulnerability or bug. Also any idea is welcome.

In reply to: #egeuq2q 1 year ago
@eapl.me

I have applied your comments, and I tried to add you as an editor but couldn't find your email address. Please request editing access if you wish.

Also, could you elaborate on how you envision migrating with a script? You mean that the client of the file owner could massively update URLs in old twts ?

In reply to: #egeuq2q 1 year ago
@eapl.me

Timeline and twtxt-php, don't support Gemini, only HTTP/S, as a design choice (although originally it was intended to work on Gemtext, it was a niche inside a niche, so it was discarded very soon).

At the moment of building the engine there weren't many Gemini URLs supporting twtxt 1.1 (with twtxt.dev extensions). Also User-Agent won't work there, and many Gemini URLs are a mirror of the HTTP one, so I think is not strictly necessary.

my 2c

In reply to: #6kqvwyq 1 year ago
@eapl.me

well... it has been an opportunity to build an artisanal microblogging client on top of a minimalist protocol. I agree on the hacker toy part.

And of course it's about being part of a niche community which is (mostly) amazing, and nurturing. As there is almost no one writing in my native spanish, it has been an interesting challenge to share my thoughts in english, as well.

I couldn't say it's a 'social network' per se, I think it lack many engagement things usually associated with social networks, although it has a social part of igniting discussions, learnings and behavioral changes, which is the meaning of social for me.

In reply to: #lrdza5a 1 year ago
@eapl.me

it seems like yarn still points my nick to both my older URL (404 now) along with the current one.

In reply to: #uavwuqq 1 year ago
@eapl.me

it seems to be "an informational website consisting of discrete, often informal diary-style text entries (posts)" https://en.wikipedia.org/wiki/Blog and https://en.wikipedia.org/wiki/Blog#History

In reply to: #6z7qt4a 1 year ago
@eapl.me

I'd like to know more about what andros and prologic are talking about, I feel lost.

"This will be managed by Registries." Are we talking about these registries? https://twtxt.readthedocs.io/en/latest/user/registry.html

In reply to: #ep5rg4q 1 year ago
@eapl.me

ah! those german calendars. Somehow I was thinking of something like mine, with spaces to write inside each day.

I worked for a german company and they gave away these calendars to our clients and team every year, but the model you can hang on the wall. Memory unlocked!

In reply to: #3nbdgya 1 year ago
@eapl.me

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. A horrible picture of the calendar on my desk

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

In reply to: #3nbdgya 1 year ago
@eapl.me

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.

In reply to: #6z7qt4a 1 year ago
@eapl.me

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.

In reply to: #ep5rg4q 1 year ago
@eapl.me

🐿️ squirrels!

In reply to: #cmoamea 1 year ago
@eapl.me

I'd need to think about it deeply, but at a first sight, nanoblogging would be a simple text (like the original twtxt spec, aimed for TUIs), and microblogging (like Twitter was a few years ago), would be about sharing texts, images, videos, GIFs, links, and perhaps Markdown styling.

Why? You have shorter messages than in a blog, but you may add almost anything you could do in a blog. Buuut... who knows?

In reply to: #6z7qt4a 1 year ago
@eapl.me

@prologic oops, I'm sorry to see disagreement leading to draining emotions.

It remind me a bit of the Conclave movie where every part wanted to defend their vision and there is only a winner. If one wins the other loses. Like the political side of many leaders and volunteers representing a broad community. I don't think that's the case here. Most of us (in not all) should 'win'.

I can only add that isn't nice to listen that 'my idea and effort' is not what the rest of the people expect. I personally have a kind of issue with public rejection, but I also like to argue, discuss and even fight a bit. "A gem cannot be polished without friction, nor a man perfected without trials," they say. This exercise and belonging to this community also brings me good feelings of smart people trying to solve a human and technical problem, which is insanely difficult to get 'right'.

I genuinely hope we can understand each other, and even with our different and respectful thoughts on the same thing, we might reach an agreement on what's the best for most people.

Good vibes to everyone!

In reply to: #tzctugq 1 year ago
@eapl.me

[lang=es] definitivamente es una buena llamada de atención para promover más donaciones a proyectos opensource. La verdad apoyo menos proyectos de los que 'debería', por el valor que me ofrecen.

Una opinión pragmática es que hay la libertad de no pagar, pero también esto nos debería llevar a que tenemos la libertad de SÍ reconocer los proyectos que nos dan valor, por medio de un donativo puntual o constante. Adaptarnos al contexto de lo que estamos ofreciendo.

Mi chava trabaja en Asociaciones Civiles (tipo OSALs/ONGs) y es un reto pedir donativos, por lo que es común pedir 'Cuotas de recuperación' pues ayudan a valorar más el servicio, y a que fluya el donativo. Creo que se puede hacer algo así en el código libre, apelando a diferentes motivadores en los usuarios.

In reply to: #5nv3ocq 1 year ago
@eapl.me

Damn! Stay safe mate...

In reply to: #rudviwq 1 year ago
@eapl.me

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

I've added a [lang=en] to this twt to see current yarn behaviour.

In reply to: #jwfdkuq 1 year ago
@eapl.me

really? I think I haven't seen it being used in the wild

In reply to: #volmoea 1 year ago
@eapl.me

@prologic sure thing! What about discussing it in https://git.mills.io/yarnsocial/twtxt.dev ? The only con I see is that everyone would need to create an account there to participate.

In reply to: #qmnnm5a 1 year ago
@eapl.me

a few async ideas for later

The editing process needs a lot of consideration and compromises.

From one side, editing and deleting it's necessary IMO. People will do it anyway, and personally I like to edit my texts, so I'd put some effort on make it work. Should we keep a history of edits? Should we hash every edit to avoid abuse? Should we mark internally a twt as deleted, but keeping the replies?

I think that's part of a more complete 'thread' extension, although I'd say it's worth to agree on something reflecting the real usage in the wild, along with what people usually do on other platforms.

In reply to: #jwfdkuq 1 year ago
@eapl.me

yep! Enjoy your rest, let's discuss it later

In reply to: #jwfdkuq 1 year ago
@eapl.me

looks good to me!

About alice's hash, using SHA256, I get 96473b4f or 96473B4F for the last 8 characters. I'll add it as an implementation example. The idea of including it besides the follow URL is to avoid calculating it every time we load the file (assuming the client did that correctly), and helps to track replies across the file with a simple search.

Also, watching your example I'm thinking now that instead of {url=96473B4F,id=1} which is ambiguous of which URL we are referring to, it could be something like: {reply_to=[URL_HASH]_[TWT_ID]} / {reply_to=96473B4F_1} That way, the 'full twt ID' could be 96473B4F_1.

In reply to: #jwfdkuq 1 year ago
@eapl.me

hi! I hope you can see this message

As in https://eapl.me/timeline/post/s7gv6zq I changed my URL to experiment on this exact situation, and deleted the symlink on my server, so now tw.txt is the only way to get the file, although I could bring it back, what does everyone say?

In reply to: #vtt2pvq 1 year ago
@eapl.me

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

In reply to: #tyiy6nq 1 year ago
@eapl.me

looks good now! description = 🏗 Full-Stack developer (Mainly Python) ✍ Writer[...]

In reply to: #zltzria 1 year ago
@eapl.me

also @Andros, I see that if I open that URL on my browser, I see weird characters in the .txt file: description = 🏗 Perhaps your nginx server is missing a Content-Type: text/html; charset=utf-8 header? https://serverfault.com/a/975289

In timeline it looks OK however, I think it's relying on

The file must be encoded with UTF-8 of the original spec: https://twtxt.readthedocs.io/en/latest/user/twtxtfile.html

In reply to: #zltzria 1 year ago
@eapl.me

working on my bookmarks tool, I found out that http(s)://domain.tls is not a valid resource, but http(s)://domain.tls/ is, as you can see here: https://stackoverflow.com/a/2581423

I suppose that internally the wget/curl or whatever client you are using is redirecting it?

In reply to: #zltzria 1 year ago
@eapl.me

here is my progress so far: https://github.com/eapl-gemugami/twtxt-direct-message-php The encryption part seems to work, if I decrypt it the message with OpenSSL. I think it can help you for some key parts not well explained in OpenSSL documentation.

@andros reading your spec I wrote a few notes here: https://github.com/eapl-gemugami/twtxt-direct-message-php/blob/main/direct_message_spec.md

@arne I haven't check your repo yet, although you are using sodium, right?

In reply to: #ztpfyia 1 year ago
@eapl.me

@andros Could you share (perhaps in the extension document) the private key for alice?

I want to compare that I can read the encrypted message both from OpenSSL CLI and from the PHP OpenSSL library, following the spec.

In reply to: #k2ob6bq 1 year ago
@eapl.me

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);
In reply to: #fyr2v5a 1 year ago
@eapl.me

I haven't taken a look into that extension, although I think you could use the OpenSSL library: https://www.php.net/manual/en/function.openssl-encrypt.php

In reply to: #k2ob6bq 1 year ago
@eapl.me

I'm surprised, here you can't find dial controls anymore. How old are your ovens? The last one my parents had was from the 90s.

I was amazed experimenting with different combinations, for instance instead of 100, using 60 for a minute, 90 for 1:30, and stupid stuff like heating with 11, 22, 55 seconds and so, to make it quicker to type any time.

In reply to: #ewuowta 1 year ago
@eapl.me

with the quote?

In reply to: #yzxedka 1 year ago
@eapl.me

among these options, 3

Although I like it more "twt", without the dot and with a t at the end

In reply to: #x6zj56a 1 year ago
@eapl.me

well, Gemini clients like Lagrange allow to show inline images when you click on an image link. Text based clients, like Amfora, usually allow to watch the image in another 'window'.

For example here: gemini://text.eapl.mx/en-making-a-tic-tac-toe-variant and there https://text.eapl.mx/en-making-a-tic-tac-toe-variant

I agree that some topics require images to make it easier to explain.

In reply to: #y4cur4q 1 year ago
@eapl.me

hey! It's looking nice

In reply to: #o2aamwq 1 year ago
@eapl.me

ok, sounds like a 'large' project to me. Is it more an API (more oriented to developers), more oriented to UI/UX/Frontend? Perhaps both?

I'd go with prologic's advice of measuring and prioritizing. Perhaps you have a budget or at least something like "let's see how far can we reach in 6 months", and possibly you won't finish in the time you have (just guessing).

Something that has helped me was defining "Why do you we want to refactor this project?". Could it be to make it compile on newer versions, or making it easier to grow and scale, or perhaps they are trying to sell that product to another company. Every reason has a different path, IMO.

In reply to: #iiqpj5a 1 year ago
@eapl.me

1st thought... Run!

Well, I've heard you have plenty of experience with Unit Testing and TDD. Perhaps designing a few tests before refactoring?

I've heard of Snapshot testing, but have never tried it: https://github.com/spatie/phpunit-snapshot-assertions

Also, what kind of refactor are you trying to do?

In reply to: #iiqpj5a 1 year ago
@eapl.me

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.

In reply to: #6x5fkia 1 year ago
@eapl.me

a year ago I had a struggle to find documentation about it and now it seems there are more examples, cool!

In reply to: #2s7hrha 1 year ago
@eapl.me

I agree 🙂, although it's easy to lose comments over time and are not so grouped by topic, it's not so easy to vote or make a survey about it...

I prefer a forum for that 😊

In reply to: #w5zgilq 1 year ago
@eapl.me

here are a few ideas you might take into consideration when designing a secure IM https://developer.virgilsecurity.com/docs/e3kit/fundamentals/secure-instant-messaging/

Obviously if you've worked on something similar, you already know it, he

In reply to: #grghd3a 1 year ago
@eapl.me

I made a draft of an "encrypted public messenger", which was basically a Feed for an address derivate from the public ket, let's say 'abcd..eaea'

Anyone could check, "are there any messages for my address?" and you get a whole list of timestamps and encrypted stuff.

Inside the encrypted message is a signature from the sender. That way you 'could' block spam.

Only the owner of the private key could see who sent what, and so...

And even with that my concussion was that users expectations for a private IM might be far away from my experiment.

In reply to: #grghd3a 1 year ago
@eapl.me

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

In reply to: #eelvuca 1 year ago
@eapl.me

my first thought is that encrypting messages with Elliptic keys is not as easy as with RSA, although I tried doing something similar a few months ago with ECIES https://github.com/eapl-gemugami/owl/blob/main/src/app/controller/ecies_demo.php

In reply to: #eelvuca 1 year ago
@eapl.me

interesting idea. I'm not personally interested on having DM conversations on twtxt (for now), although I see the community could be interested in.

I'd suggest to enable the Discussion section in your Github repo to receive comments, as we did for timeline https://github.com/sorenpeter/timeline/discussions

In reply to: #eelvuca 1 year ago
@eapl.me

although I agree that it helps, I don't see completely correct to leave the nick definition to the source .txt. It could be wrong from the start or outdated with the time.

I'd rather prefer to get it from the mentioned .txt nick metadata (could be cached for performance). So my vote would to make it mandatory to follow <a href="/timeline/profile?url=url">@name</a><a href="url" class="webmention"></a> but only using that name/nick if the URL doesn't contain another nick. A main advantage is that when the destination URL changes the nick, it'll be automagically updated in the thread view (as happens with some other microblogging platforms, following the Jakob's Law)

In reply to: #wdmf56a 1 year ago
@eapl.me

word of the thay, prosoal Is it a typo of Proposal right? =P (Genuinely asking)

In reply to: #ot56hla 1 year ago
@eapl.me

nice! would you mind elaborating a bit? Is that the scientific method? I couldn't find anything related when I searched for it.

In reply to: #2x7jyga 1 year ago
@eapl.me

Django channels are cool! I had the chance to make a online gaming framework with Channels and Django Rest and was a great experience.

I'm looking forward to doing something in Django LiveView soon.

In reply to: #m5ib2va 1 year ago
@eapl.me

and going back to a handle you could input in your client to look for the user/file, like @nick@domain.tls I think Webfinger is the way to go. It has enough information to know where to find that nick's URL.

@prologic does that webfinger fork made by darch work OK with yarn as it is now? (I've never used it, so I'm researching about it) https://darch.dk/.well-known/webfinger/

In reply to: #6qodp6q 1 year ago
@eapl.me

Oh no! Wife and I agreed on hibernate until January, just visiting relatives but avoiding any kind of shopping. I tried buying something like 2 or 3 days ago and it's insane :o

Good luck! :)

In reply to: #i5p7xta 1 year ago
@eapl.me

I'm just having a similar issue with a podcast I just uploaded on Castopod (which supports ActivityPub).

My first thought was creating a subdomain with the name of the podcast mordiscos.eapl.me

Then I watched that the software allows many podcasts in the same domain, so I had to pick a handle: https://mordiscos.eapl.me/@podcast

So now I have @podcast@mordiscos.eapl.me when this one is 'more correct' @mordiscos@podcast.eapl.me or it could even be @mordiscos.eapl.me I wasn't aware of all that when I setup Castopod (documentation might improve a lot, IMO)

My point here is that it's something important to think from the start, otherwise is painful to change if it's already being used like that.

In reply to: #gc55n3a 1 year ago
@eapl.me

my 2 cents here... I agree on displaying a short @nick.

We could hover on the nick to see the full detail which could be @nick@domain.tls or the full URL Also it could be a display option in Preferences in case your account starts showing many collisions.

The disambiguation for collisions is the .txt URL and the nick inside it, right ?

In reply to: #6qodp6q 1 year ago
@eapl.me

BTW I'm watching that darch has already worked on that, interesting https://github.com/sorenpeter/timeline/blob/main/_webfinger-endpoint/.well-known/webfinger/index.php

In reply to: #6qodp6q 1 year ago
@eapl.me

hey!

In reply to: #hsyv65q 1 year ago
@eapl.me

I think we could discuss on implementation details like URLs and Handles.

@nick@eapl.me (Masto/Yarn style) vs @nick.eapl.me and @eapl.me (Bsky style)

I see, for example, that yarn shows my account as @eapl.me@eapl.me which looks 'weird' although it's not wrong since my domain and my nick are the same. Honestly I like more the Bsky approach as in https://bsky.app/profile/eapl.me for @eapl.me, as when you look for https://eapl.me, it's my home page.

Also, I didn't get it completely if you are also proposing a URL standard using subdomains, like https://nick.domain.tls. I only want to point out that these are more difficult to handle from shared hostings, so I'd prefer to also allow https://domain.tls/nick/

In reply to: #6qodp6q 1 year ago
@eapl.me

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)

In reply to: #6qodp6q 1 year ago
@eapl.me

since twtxt is based on text files, I think you can consider @domain.tld as an alias of http://domain.com/twtxt.txt (or https://domain.com/tw.txt, among other combinations in the wild).

Or perhaps you can use DNS TXT records? Although I think that's a bit more complicated for some environments and users, I'd go with looking for a default /tw*.txt

In reply to: #624dwtq 1 year ago
@eapl.me

haha, that's gold xD.

#randomMemory I remember when I was starting to code, like 30 years ago, not understanding why my Basic file didn't run when I renamed it to .exe

And nowadays, I've seen a few Go apps in a single executable, so twtxt.exe could be a thing, he!

In reply to: #wl4utia 1 year ago
@eapl.me

well, the extension helps to know the file format as in .txt and .html, perhaps .twt, he!

In reply to: #j7i6yra 1 year ago
@eapl.me

Want to help improve the shoddy code?

In reply to: #c6ittpa 1 year ago
@eapl.me

Hehe, although it isn't a fancy language PHP has improved a lot since the old PHP 5 days ¯_(ツ)_/¯ It's 3 to 5 times slower than Go, so I think that's not too bad

In reply to: #c6ittpa 1 year ago
@eapl.me

My bad! My editor was set to use 4 spaces instead of a tab... Making twts by hand is hard =P

In reply to: #gjhq2xq 1 year ago
@eapl.me

Also I'm thinking on adding support for If-Modified-Since since it'll improve the refreshing process 🤔

In reply to: #gjhq2xq 1 year ago
@eapl.me

Hey! I tried running Timeline on my server with the default PHP version (8.3) and it's giving me a few errors https://eapl.me/timeline/ I should be sending a PR soon to fix it ;)

In reply to: #gjhq2xq 1 year ago
@eapl.me In reply to: #w7qc4ra 1 year ago
@eapl.me

Damn, it's certainly broken. Thank you for letting me know! I'm editing my .txt file by hand, and it seems WinSCP editor doesn't support that character and replaced them all =/

In reply to: #fn4euca 1 year ago
@eapl.me

Hehe, thank you guys, I'm still alive :)

In reply to: #nvrq7lq 1 year ago
Comment via email