Image

Well because I can and want to see what will happen :)

But Yarn does not like it: https://twtxt.net/twt/yoatzwa

@ You seem to be a bit ahead of your time: https://darch.dk/timeline/conv/jl2mf2a

Yes it seem to work(ish) on timeline at least: https://darch.dk/timeline/post/imopblq

@bender@twtxt.net My point was that the suggested syntax for extending mentions to point to a specific message (@<nick url timestamp>) and having location based treading this way, might not break older clients, since they might just igonore the last value within the brackets.

@ About the URL, since it no longer used for hashing there might be no need to change it. I agree that we keep all the parts that already are out there for the most parts. Instead of a contact field you could also just use links like: link = Email mailto:user@example.dk or link = Signal https://signal.me/sthF4raI5Lg_ybpJwB1sOptDla4oU7p[...]

@andros@twtxt.andros.dev Thanks for consolidating a lot of good ideas. Especially how you have deiced to just extend the mention syntax for location-based treads. This might even be backward compatible with older (pre-yarn) clients.
What about using Z for UTC +00:00- is that allowed in your specs?
Regarding url = I would suggest to only allow one and the maybe add url_old = or url_alt = !?
I’m still not a fan of a DM feature, even thou it helps that i have now been split out into a separate feed file. Instead if would suggest a contact = field for where people can put an email or other id/link for an established chat protocol like signal or matrix.

@movq@www.uninformativ.de I didn’t say I was leaving, just not that active here atm. I might be more active on mastodon at https://norrebro.space/@sorenpeter but I’m also rethinking that too tbh.

I’m with @andros@twtxt.andros.dev and @eapl.me@eapl.me on this one. But I have also lost interest in twtxt lately and currently rethinking what digital tools truly add value to my life. So I will not spending my time on adding more complexity to Timeline. Still a big thanks to you @prologic@twtxt.net for all the great work you have done and all the nice conversations both here and on our video calls.

@prologic@twtxt.net it was not an edit but a double posting

Hi @lyse@lyse.isobeef.org, I canceled the domain, so neotxt or my feed there are not coming back.

yes it used be http:// only and to keep hashes from breaking i added # url = http://... and now we are stock with it due to the curret specs.

#testing @ Hi Bob, nice to meet you!

If we don’t keep insisting on simplify and “The beauty of twtxt is, you put one file on your server, done. One.”, then people should just use ActivityPub-based software like Mastodon, PixelFed, etc. which are getting a lot of attention and uses migrating to the fediverse from meta/x here in Denmark over the last couple of months.

yes it works now :)

@prologic@twtxt.net All the URL are missing the protocol part (https://) and my markdown parser does not know how to handle but I see yarnd does it just fine.

@falsifian@www.falsifian.org
it look like your markdown image tags are missing the protocol part (https://) so they don’t render at least on my server: https://darch.dk/timeline/conv/3vtnszq

@andros@twtxt.andros.dev Thank you :-)

@andros@twtxt.andros.dev screenshots plz :=!

Added support for uploading images to to #Timeline

Image

What exact feeds are we talking about that uses spaces instead of tabs or the T’s in timestamp?

So what are some good alternatives to GitHub, that are not based in USA?
I like the minimal feel of sourcehut but it seem you have to pay if you want your, not just submit patches to others repos. But they also got IRC bouncer and mailing-lists included. Codeberg also looks appealing being based in Germany.

@lyse@lyse.isobeef.org that 3th shot of the heron taking off is epic!

@aelaraji@aelaraji.com I’ve been noticing the same, so I opened an issue now (https://github.com/sorenpeter/timeline/issues/55) and then we will have to look into it.

#genuary #genuary2025 #genuary17 Maybe related to today prompt: What happens if pi=4? https://youtu.be/tGfUaZ8hTzg

@arne@uplegger.eu nice work with the client.
I also see you are using the Yellow CMS for your website🍋

@doesnm.p.psf.lt@doesnm.p.psf.lt Are you also using https://cabal.chat or just someone else with the same random username?

@doesnm.p.psf.lt@doesnm.p.psf.lt Cool lets see if this works?!

@prologic@twtxt.net I say we should find a way to support mentions with only url, no nick, as per the original spec.

• For @<nick url> we already got support
  
• For @<nick> the posting client should expand it to @<nick url>, if not then the reading client should just render it as @nick with no link.
  
• For @<url> the sending client should try to expand it to @<nick url>, if not then the reading client should try to find or construct a nick base on:
  
  1. Look in twtxt.txt for a nick =
     
  2. Use (sub)domain from URL
     
  3. Use folder or file name from URL

hmm any ideas how to fix this case when there is no nick and it on a shared tilde hosting? http://darch.dk/timeline/profile?url=https://tilde.club/~deepend/twtxt.txt

@doesnm@doesnm.p.psf.lt How did you post from IndiePass? Did you add support for twtxt or use some kind of bridge?

I’ve implemented Use only nick as handle if nick and domain is the same · sorenpeter/timeline@8c12444

See it live at:

• nick = domain: https://darch.dk/timeline/profile?url=https://eapl.me/tw.txt
  
• nick ≠ domain: https://darch.dk/timeline/profile?url=https://twtxt.net/user/prologic/twtxt.txt
  
• no nick, use domain: https://darch.dk/timeline/profile?url=https://akkartik.name/twtxt.txt
  

I’m not sure I like the leading @ thou…

What should the advantage be to nick = _compared to just not defining a nick and let the client use the domain as the handle?

What is not intuitive is that you put something in the nick field that is not to be taken literary. The special meaning of _ is only clean if you read the documentation, compared to having something in nick that makes sense in the current context of the twtxt.txt.

@doesnm@doesnm.p.psf.lt So the user should then set nick = _@domain.tld in the twtxt.txt?

It seems more intuitive and userfriendly to just use: nick = domain.tld and have then convention for clients to render the handle as @domain.tld instead of @domain.tld@domain.tld

For a feed with no nick defined (eg. https://akkartik.name/twtxt.txt) it will also be simpler and make more sense to just use the domain as the nick and render it as @domain.tld

Are we talking about profile view heading, heading of posts or inline mentions?

Image

@eapl.me@eapl.me A way to have a more bluesky’ish handles in twtxt could be to take inspiration from Bridgy Fed and say: If NICK = DOMAIN then only show @DOMAIN
So instead of @eapl.me@eapl.me it will just be @eapl.me

And it event seem that it will not break webfinger lookup: https://webfinger.net/lookup/?resource=%40darch.dk (at least not for how I’ve implemented webfinger on my sever for a single user;)

I’ve started a draft over at: https://git.mills.io/yarnsocial/twtxt.dev/src/branch/main/exts/webfinger.md

@prologic@twtxt.net maybe you meant to specify twtxt as a type similar to ActivityPub’s application/activity+json in https://webfinger.net/lookup/?resource=sorenpeter@norrebro.space

    {
      "rel": "self",
      "type": "application/activity+json",
      "href": "https://norrebro.space/users/sorenpeter"
    },

Then it would also make sense to define a Link Relations but should that then link to something like https://twtxt.dev/webfinger.html where we can describe the spec?

@prologic@twtxt.net Well I just mirrored yarnd’s JSON in my webfinger endpoint and lookup, so not much else to do for standardization.

And for people who don’t like PHP you can always just go with Added WebFinger support to my email address using one rewrite rule and one static file. or simply putting a static JSON in place for .well-know/webfinger

I like the cleaness and indiewebness of using just domains for handles/shorthands similar to blusky, but the situations with more users on the same domain and that people in the fediverse (threads too?) are already familiar with the syntax speaks for webfinger. And since we already got support for webfinger in both yarnd and timeline it makes sense to stick with it.

@movq@www.uninformativ.de Where in firefox can I set custom CSS?

test

@prologic@twtxt.net What IRC client is that?

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

@movq@www.uninformativ.de I will take that as a compliment

Wow, it seem my #Webmentions implementation works from Mastodon via brid.gy

Image

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@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@lyse.isobeef.org One person had came access it before, but no tried it

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

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

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

@johanbove@johanbove.info Thanks, I’m glad you like it.

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

“A minimalist social network powered by plain text files” - my talk about #twtxt from #Piksel24 Festival is now on YouTube and slides can be found at http://darch.dk/twtxtalk-piksel

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@twtxt.net 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@aelaraji.com - And I can confirm that my #webmentions works from your server

Image

Hey @aelaraji@aelaraji.com I’m running PHP 8.2 on my server

@movq@www.uninformativ.de I knew you would like it;)

Seven Bit Encoding by Dylan Beattie #music

@eapl.me@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?

Would it make sense for twtxt v.2 to do something similar to bluesky, where you use a domain as you handle by creating a specific DNS record as explained by: https://matthiasott.com/notes/how-to-set-your-domain-as-your-bluesky-handle

What are peoples #IRC setup? Do you have your own bouncer server or just have a you computer always on? And do you IRC on mobile?

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

@movq@www.uninformativ.de 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@www.codebuzz.nl 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.

Simplified twtxt - I want to suggest some dogmas or commandments for twtxt, from where we can work our way back to how to implement different feature like replies/treads:

1. It’s a text file, so you must be able to write it by hand (ie. no app logic) and read by eye. If you edit a post you change the content not the timestamp. Otherwise it will be considered a new post.

2. The order of lines in a twtxt.txt must not hold any significant. The file is a container and each line an atomic piece of information. You should be able to run sort on a twtxt.txt and it should still work.

3. Transport protocol should not matter, as long as the file served is the same. Http and https are preferred, so it is suggested that feed served via Gopher or Gemini also provide http(s).

4. Do we need more commandments?

@prologic@twtxt.net Why does twtxt.net still show my old avatar?

@Codebuzz@www.codebuzz.nl Welcome to the twt’verse 👋

@doesnm@doesnm.p.psf.lt finally someone read my blogpost ;)

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

Video of my latest #livecoding show using #punctual for #visuals
https://www.youtube.com/watch?v=CsM39SpRik8

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

@2024-10-09T08:11:00Z@twtxt.net 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@a.9srv.net 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@collantes.us, good to know, but we need to agree on what character we use, otherwise the hashes will not be the same:)

@prologic@twtxt.net 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@twtxt.net 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) What does this screenshot show? The resolution it too low for reading the text…

(#2024-09-24T12:45:54Z) @prologic@twtxt.net 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) There is a increase in space/memory for sure. But calculating the hashes also takes up CPU. I’m not good with that kind of math, but it’s a tradeoff either way.

(#2024-09-24T12:39:32Z) @prologic@twtxt.net 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@www.uninformativ.de 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) 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: (#<DATE URL>) or (@<DATE URL>) 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 (#<DATE URL>) will also make mentions via webmetions for 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@www.uninformativ.de 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@twtxt.net what time in UTC?

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

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