@aelaraji https://github.com/sorenpeter/timeline/commit/555baefcd0e75e6a281472994e8eb7ae9b5d2a1c

@movq I will take that as a compliment

good luck with the doughnut on a stick in a URL

or timeline.txt ;)

test post EDIT

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

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

Access to those files are closed to the public.

My twtAgent.php was turned off, so try again now. I have uploaded the code to: https://github.com/sorenpeter/twtAgent

What was it suppose to look like? a <detail><summary>-tag maybe?

@eapl.mx Yes, the idea is to add User Agent support to #Timeline. Right now it just adds every request to a growing log file, but I have also been working on a way to analyse it, so it only saves the time of the latest request. I'm not sure how to make it part of timeline itself, since it requeses that you redirect/rewrite from twtAgent.php to the acctual twtxt.txt Help with making Timeline send proper User Agents to others would be much appreciated:)

@lyse One person had came access it before, but no tried it

@prologic Just that people thought twtxt sounded cool and maybe want to set it up themself

@eapl.mx Super to see you got webmentions working too :)

EDIT: A webmention was send to: https://eapl.mx/timeline/webmention (Status: 202)

@johanbove Thanks, I'm glad you like it.

@movq There was no time for discussion just after the presentation, but I had a chat with some folks later.

Because I don't have capacity on my server to host and stream video and I want others to be able to find the video.

I'm gonna upload my part of the video to youtube and the slides to my website within a day or two. Then you can add it to yarn.social etc.

Live from Piksel Festival in about an hour via: https://www.twitch.tv/pikselfest - Also other presentations stating momentary

I'm giving a shot talk about twtxt/yarn/timeline tommow around noon CET at Piksel Festival in Norway. More info and link for live stream at: https://24.piksel.no (So I will most likely not be joining the call)

@bender The tagline of Timeline is "a single user twtxt/yarn pod" not just a yarn pod. Similar to GNU/Linux. When we came up with the concept of Yarn Social it was a way to rebrand twtxt with the extensions that makes conversations like this possible.

Great to see another user @aelaraji - And I can confirm that my #webmentions works from your server (I know, the formatting is messed up;)

Hey @aelaraji I'm running PHP 8.2 on my server

@movq I knew you would like it;)

@eapl.me here are my replies (somewhat similar to Lyse's and James')

1. Metadata in twts: Key=value is too complicated for non-hackers and hard to write by hand. So if there is a need then we should just use #NSFS or the alt-text file in markdown image syntax ![NSFW](url.to/image.jpg) if something is NSFW

2. IDs besides datetime. When you edit a twt then you should preserve the datetime if location-based addressing should have any advantages over content-based addressing. If you change the timestamp the its a new post. Just like any other blog cms.

3. Caching, Yes all good ideas, but that is more a task for the clients not the serving of the twtxt.txt files.

4. Discovery: User-agent for discovery can become better. I'm working on a wrapper script in PHP, so you don't need to go to Apaches log-files to see who fetches your feed. But for other Gemini and gopher you need to relay on something else. That could be using my webmentions for twtxt suggestion, or simply defining an email metadata field for letting a person know you follow their feed. Interesting read about why WebMetions might be a bad idea. Twtxt being much simple that a full featured IndieWeb sites, then a lot of the concerns does not apply here. But that's the issue with any open inbox. This is hard to solve without some form of (centralized or community) spam moderation.

5. Support more protocols besides http/s. Yes why not, if we can make clients that merge or diffident between the same feed server by multiples URLs

6. Languages: If the need is big then make a separate feed. I don't mind seeing stuff in other langues as it is low. You got translating tool if you need to know whats going on. And again when there is a need for easier switching between posting to several feeds, then it's about building clients with a UI that makes it easy. No something that should takes up space in the format/protocol.

7. Emojis: I'm not sure what this is about. Do you want to use emojis as avatar in CLI clients or it just about rendering emojis?

I'm planning to be there tomorrow (message from yesterday, since we can not all live in the future;)

@movq How hard would it be to implement something like (#<2024-10-25T17:15:50Z https://www.uninformativ.de/twtxt.txt>)in jenny as a replacement for (#twthash) and have it not care about if is http(s) or a g-protocol?

@Codebuzz Speed is an issue for the client software, not the format itself, but yes I agree that it makes the most sense to append post to the end of the file. I'm referring to the definition that it's the first url = in the file that is the one that has to be used for the twthash computation, which is a too arbitrary way of defining something that breaks treading time and time again. And this is the case for not using url+date+message = twthash.

@doesnm finally someone read my blogpost ;)

@aelaraji Thank you, and yes I got more on my websites https://darch.dk/vj/ and https://algorave.dk/videos/

I know no client support it (yet) - but it could be the future 😅

@2024-10-09T08:11:00Z It an easy way of twt-adressing by using the timestamp instead of a nick, which is arbitrary anyhow. Just my suggestion for a new reply-model ;)

@2024-10-08T19:36:38-07:00 Thanks for the followup. I agrees with most of it - especially:

Please nobody suggest sticking the content type in more metadata. 🙄

Yes, URL can be considered ugly, but they work and are understandable by both humans and machines. And its trivial for any client to hide the URLs used as reference in replies/treading.

Webfinger can be an add-on to help lookup people, and it can be made independent of the nick by just serving the same json regardless of the nick as people do with static sites and a as I implemented it on darch.dk (wf endpoint). Try RANDOMSTRING@darch.dk on http://darch.dk/wf-lookup.php (wf lookup) or RANDOMSTRING@garrido.io on https://webfinger.net

Thanks @david, good to know, but we need to agree on what character we use, otherwise the hashes will not be the same:)

@prologic Regarding the new way of generating twt-hashes, to me it makes more sense to use tabs as separator instead of spaces, since the you can just copy/past a line directly from a twtxt-file that already go a tab between timestamp and message. But tabs might be hard to "type" when you are in a terminal, since it will activate autocomplete...🤔

Another thing, it seems that you sugget we only use the domain in the hash-creation and not the full path to the twtxt.txt

$ echo -e "https://example.com 2024-09-29T13:30:00Z Hello World!" | sha256sum - | awk '{ print $1 }' | base64 | head -c 12

@prologic YES James, it should be up to the client to deal with changes like edits and deletions. And putting this load on the clients, location-addressing with make this a lot easier since what is says it: Look in this file at this timestamp, did anything change or went missing? (And then threading will not break;)

why can we both have a format that you can write by hand and better clients?

yes that works

(#<2024-09-24T12:53:35Z https://twtxt.net/user/prologic/twtxt.txt>) What does this screenshot show? The resolution it too low for reading the text...

(#<2024-09-24T12:45:54Z https://twtxt.net/user/prologic/twtxt.txt>) @prologic I'm not really buying this one about readability. It's easy to recognize that this is a URL and a date, so you skim over it like you would we mentions and markdown links and images. If you are not suppose to read the raw file, then we might a well jam everything into JSON like mastodon

(#<2024-09-24T12:44:35Z https://twtxt.net/user/prologic/twtxt.txt>)

(#<2024-09-24T12:39:32Z https://twtxt.net/user/prologic/twtxt.txt>) @prologic It might be simple for you to run echo -e "\t\t" | sha256sum | base64, but for people who are not comfortable in a terminal and got their dev env set up, then that is magic, compared to the simplicity of just copy/pasting what you see in a textfile into another textfile -- Basically what @movq also said. I'm also on team extreme minimalism, otherwise we could just use mastodon etc. Replacing line-breaks with a tab would also make it easier to handwrite your twtxt. You don't have to hardwrite it, but at least you should have the option to. Just as i do with all my HTML and CSS.

(#<2024-09-24T12:34:31Z https://twtxt.net/user/prologic/twtxt.txt>) WebMentions does would work if we agreed to implement it correctly. I never figured out how yarnd's WebMentions work, so I decide to make my own, which I'm the only one using...

I had a look at WebSub, witch looks way more complex than WebMentions, and seem to need a lot more overhead. We don't need near realtime. We just need a way to notify someone that someone they don't know about mentioned or replied to their post.

Some more arguments for a local-based treading model over a content-based one:

1. The format: `or(@DATE)both makes sense: # as prefix is for a hashtag like we allredy got with the(#twthash)` and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.

2. Having something like `will also make mentions via [webmetions for twtxt](https://darch.dk/mentions-twtxt) easier to implement, since there is no need for looking up the#twthash`. This will also make it possible to make 3th part twt-mentions services.

3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don't follow.

@movq I cases of these kind of "abuse" of social trust. Then I think people should just delete their replies, unfollow the troll and leave them to shouting in the void. This is a inter-social issue, not a technical issue. Anything can be spoofed. We are not building a banking app, we are just having conversation and if trust are broken then communication breaks down. These edge-cases are all very hypothetical and not something I think we need to solve with technology.

Been thinking about it for the last couple of days and I would say we can make do with the shorter (#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?

@prologic what time in UTC?

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

@prologic you will always be replying to OP - that is what the twthash is a shorthand for, it it not?!

no my fault your client can't handle a little editing ;)

@movq I'm glad you like it. A mention (<a href="/timeline/profile?url=https://www.uninformativ.de/twtxt.txt">@movq</a><a href="https://www.uninformativ.de/twtxt.txt" class="webmention"></a>) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!

@mckinley Thanks for the feedback.

1. Yeah I agrees that nick sound not be part of syntax. Any valid URL to a twtxt.txt-file should be enough and is more clear, so it is not confused with a email (one of the the issues with webfinger and fedivese handles)
2. I think any valid URL would work, since we are not bound to look for exact matches. Accepting both http and https as well as a gemni and gophe could all work as long as the path to the twtxt.txt is the same.
3. My idea is that you quote the timestamp as it is in the original twtxt.txt that you are referring to, so you can do it by simply copy/pasting. Also what are the change that the same human will make two different posts within the same second?!

Regarding the whole cryptographic keys for identity, to me it seems like an unnecessary layer of complexity. If you move to a new house or city you tell people that you moved - you can do the same in a twtxt.txt. Just post something like "I move to this new URL, please follow me there!" I did that with my feeds at least twice, and you guys still seem to read my posts:)

The tag URI scheme looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick?

Instead of using tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:

1. (reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)
2. (in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
3. (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)

I know it's longer that 7-11 characters, but it's self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex: \([\w-]*reply[\w-]*\:

Is this something that would work?

Thank you @aelaraji, I'm glad you like it. I use PHP because it's everywhere on cheap hosting and no need for the user to log into a terminal to setup it up. Timeline is not mean to be use locally. For that I think something like twtxt2html is a better fit. (and happy to see you using simple.css on you new log page;)

I was not suggesting to that everyone need to setup a working webfinger endpoint, but that we take the format of nick+(sub)domain as base for generating the hashed together with the message date and content.

If we omit the protocol prefix from the way we do things now will that not solve most of the problems? In the case of gemini://gemini.ctrl-c.club/~nristen/twtxt.txt they also have a working twtxt.txt at https://ctrl-c.club/~nristen/twtxt.txt ... damn I just notice the gemini. subdomain.

Okay what about defining a prefers protocol as part of the hash schema? so 1: https , 2: http 3: gemini 4: gopher ?

@prologic do that mean that for every new post (not replies) the client will have to generate a UUID or similar when posting and add that to to the twt?

how little data is needed for generating the hashes? Instead of the full URL, can we makedo with just the domain (example.net) so we avoid the conflicts with gemini://, https:// and only http:// (like in my own twtxt.txt) or construct something like like a webfinger id nick@domain (also used by mastodon etc.) from the domain and nick if there, else use domain as nick as well

For following notifications I would say use webmetion refering to the the line in your twtxt.txt as per: https://darch.dk/mentions-twtxt Or send them an email, so it would be an idea to add a # contact = mailto:me@domain.net to ones twtxt.txt

This reminds me of this video: The Biggest Gap in Science: Complexity However you might end up with more questions (complexity?) than answers (simplicity?)

Have not tried any of them, but some of these seem to fit the bill:

• https://chromewebstore.google.com/search/Redirector
• https://libredirect.github.io/
• https://requestly.com/products/web-debugger/

ok != perfect

It looks okay on my timeline: http://darch.dk/timeline/conv/omu7e4q

@prologic The old options are still valid, so "Show latest post per feed" should just be added as a 3th.

I think it is a good addition. Similar to how the Fraidycat RSS reader works. Fraidyc.at also support twtxt, but have not seen any updates since 2021...

Here now too

echo chambers?

I fixed it by adding (?<!\S) to the regex filter. But what is going on with the ?nick=dbucklin anyhow?

@movq Maybe something for you: 7.css - A CSS framework for recreating Windows 7 UI

@prologic Haha, that sh!t is pure (net)art!

@dfaria the difference is that these other servers does not post several times a day with content that are not informative/interesting to people outside your academic context, which can be perceived as noise.

What @prologic have done is what I would call curation of the service he offers to the world for free (as in beer). It's no one right to have their posts syndicated to the frontpage of twtxt.net, it's simply a gift he gives to the world and he is free (as in speak) to wrap is anyway he sees fit.

@dfaria.eu I hope you stay around 🌞

@prologic and @bender for a start a single user twtxt/yarn pod could look like this 😉

The wording can be more subtle like "This feed have not seen much activity within the last year" and maybe adding a UI like I did in timeline showing time ago for all feeds

I agree that it good to clean up the Mastodon re-feeds, but it should also be okay for anyone to spin up a twtxt.txt just for syndicating they stuff from blog or what ever.

The "not receiving replies" could partly be fixed by implementing a working webmentions for twtxt.txt

@hecanjog You need to include the full URL for the audio file for this to work across servers/pods ;)

yes i know @bender, it's on my to-do

yes i know @bender, it's on my to-do

@bender you can over at http://darch.dk/timeline/conv/ba3xbfa or by looking at the raw txt https://lyse.isobeef.org/twtxt.txt I can't help it that twtxt.net only have temporary caching ¯_(ツ)_/¯

Thanks for your feedback @lyse. For some reason i missed it until now. For now I have implemented endpoint discovery for #webmentions as a metadata field in the twtxt.txt like this: # webmention = http://darch.dk/timeline/webmention

I like the self-shot in the mud: https://lyse.isobeef.org/waldspaziergang-2024-04-07/43.jpg

And now added #filter for replies too:

Hi @movq, is it better now? I have put in a psudo twthash since I did not archive from a specific date/post, but just what I did not find relevant to keep in my main feed.

you need to send an email @quark if you want an account. I know that it might not be very profitable. Maybe Odo can disclose it if I give him a new bucket.

@mckinley I'm over here now. And yes I can send a PR to repo or your are welcome to add it. Credits also to @eapl.me for making a working yarn compatible parser.

What? was? that? Music videos in the 90s was just something else. Especially like the guy in the straitjacket on a pogostick

Same, got one more day at the office, but most folks are already away and the city have shifted from locals to tourists 🌞

It not that easy @xuu since I implemented webmentions in a different way that how it have been done in yarnd to work with txt-files. You can find the code in webmention_endpoint.php and new_twt.php at main · sorenpeter/timeline

Thanks @prologic, I also just manage to get my own version of webmentions working. Please have a read at Webmentions vs. Custom Mentions Spec for Twtxt/Yarn - HedgeDoc and User Lookup for Twtxt/Yarn - Webfinger or Decentralized Identifiers (DIDs) - HedgeDoc for how it sorta works

@movq For syncing notes between computers and phones I've been very happy with Simple Text - w Dropbox sync for some year, but transitioned to Joplin around new year. Both sync via Dropbox and for Joplin there are also more free options. I guess you could even use something like Syncthing

Also made a webfinger lookup resolver that works with my own webfinger endpoint as well as yarnd servers: http://darch.dk/wf-lookup.php

Just hacked together this small webfinger endpoint to be used as a companion with timeline: .well-known/webfinger/index.php at main · sorenpeter/timeline

So where do we start wring down the specs/protocol for twtxt2/yarn?

@shreyan What do you mean when you say federation protocol?

• Either use webfinger for identity like mastodon etc. or use ATproto from Bluesky (or both?)

• We can use webmentions or create our own twt-mentions for notifying someones feed (WIP code at: https://github.com/sorenpeter/timeline/tree/webmention/views)

I'm not sure we need much else. I would not even bother with encryption since other platforms does that better, and for me twtxt/yarn/timeline is for making things public

yeah, where and how can we sign up?

It already works: https://webfinger.net/lookup/?resource=xuu%40txt.sour.is but it not very well described afak

I like this one the most

I'm also more in favor of #reposts being human readable and writable. A client might implement a bottom that posts something simple like: #repost Look at this cool stuff, because bla bla [alt](url)

This will then make it possible to also "repost" stuff from other platforms/protocols.

The reader part of a client, can then render a preview of the link, which we talked about would be a nice (optional) feature to have in yarnd.

What about using the blockquote format with > ?

Snippet from someone else's post by: @eapl.me

Would it not also make sense to have the repost be a reply to the original post using the (#twthash), and maybe using a tag like #repost so it eaier to filter them out?

danke schøn, yes the idea was that it should work for all feeds

@johanbove Sounds interesting. It is only for reading or also posting?

I think is part of the code by @eapl.me that I have based my project on. So try to ask him.

Gracias. Also the git repo now contain code that should actually work

Thank you @lyse - yeah they are kinda crazy color wheels

@prologic it seem to work just fine for the most part. http://darch.dk/twtxt.txt for refernce

@prologic @darch Thank you for making twt.social etc:) I don't think I have been this involed in a open source project before.