@prologic@twtxt.net Of course you don’t notice it when yarnd only shows at most the last n messages of a feed. As an example, check out mckinley’s message from 2023-01-09T22:42:37Z. It has “[Scheduled][Scheduled][Scheduled]“… in it. This text in square brackets is repeated numerous times. If you search his feed for closing square bracket followed by an opening square bracket (][) you will find a bunch more of these. It goes without question he never typed that in his feed. My client saves each twt hash I’ve explicitly marked read. A few days ago, I got plenty of apparently years old, yet suddenly unread messages. Each and every single one of them containing this repeated bracketed text thing. The only conclusion is that something messed up the feed again.

@eapl.me@eapl.me Yeah, you need some kind of storage for that. But chances are that there’s already a cache in place. Ideally, the client remembers etags or last modified timestamps in order to reduce unnecessary network traffic when fetching feeds over HTTP(S).

A newsreader without read flags would be totally useless to me. But I also do not subscribe to fire hose feeds, so maybe that’s a different story with these. I don’t know.

To me, filtering read messages out and only showing new messages is the obvious solution. No need for notifications in my opinion.

There are different approaches with read flags. Personally, I like to explicitly mark messages read or unread. This way, I can think about something and easily come back later to reply. Of course, marking messages read could also happen automatically. All decent mail clients I’ve used in my life offered even more advanced features, like delayed automatic marking.

All I can say is that I’m super happy with that for years. It works absolutely great for me. The only downside is that I see heaps of new, despite years old messages when a bug causes a feed to be incorrectly updated (https://twtxt.net/twt/tnsuifa). ;-)

Definitely something going on with replies. This one was replying to the wrong twt and even when I got clever and pasted the right hash it didn’t work.

@prologic@twtxt.net the code block is the cause of https://txt.sour.is/twt/zn2kg7q

and the second? i get POST errors when i try to submit the webform.

@mckinley@twtxt.net And there is the bracketed text duplication bug again… Actually with lots of twts. Did you edit a twt? Do you remember? /cc @prologic@twtxt.net

Well, that’s another bug: The search https://twtxt.net/search?q=%22LOOOOL%2C+great+programming+tutorial+music%22 yields the wrong hash. It should have been poyndha instead.

alert the twt police!!

I have a paper deadline coming up, so will everyone please stop writing twts for the next 48 hours, thanks.

@andros@twtxt.andros.dev Sweeeeet! Just gave it a try, you’ve done a wonderful work 🫡 I wanted to replay from there but couldn’t go past the first page of the feed. It kept freezing on me and complaining about some bad Url (as mentioned on the test twt), so I’ll have to dig through my follow list and see where I effed up this time. 😅

Here’s a twt from @andros@twtxt.andros.dev ’s new version of Twtxt-el 🥳 It feels WAaaaaY better! although it freezes on me as soon as I navigate to the next page complaining about some bad url, but the chronological sorting of the feed as well as the navigation buttons (links?) are a great addition. Looking forward to the next update already! 😁 🥳🥳🥳

Ok, it’s really spam account: https://twtxt.net/twt/xu3u7zq . Damn spammers. Can you delete this?

https://twtxt.net/twt/nbl4xfq

@lyse@lyse.isobeef.org @prologic@twtxt.net 😆 There was something weird going on with my #Timeline instance, the text input box was visible even though I was logged out and I was able to twt from it … It has to do with cache because it wouldn’t disappear unless I whip my website’s cache from the browser.

Poke @sorenpeter@darch.dk and @eapl.me@eapl.me I have no Idea how to reproduce this.

It seems related to us poor single user pods not getting the trust to share twts.. which it seems to still untrust on restart for me.

@movq, @prologic@twtxt.net when navigating to a Yarn. If the head twt is missing then the whole thread is not accessible. It only returns an error. so i have no way to view any of the replies within the thread other than the end twt.

Or using the same twt hash method, but only for the URL, to generate the nick, if it doesn’t exist, like so, @5vxo4ia@twtxt.net

Lol why you and bender twts are rendered but my with simular content are skipp3d? Upd: nevermind, i’m dumb, my twt are created in future because i type date -iS and replaces +03:00 with Z: https://twtxt.net/twt/yctmi7a

@doesnmppsflt@doesnm.p.psf.lt Not sure which bug you’re referring to. 🤔 (Did I forget?)

Those long IDs like (#113797927355322708) are simply part of that feed. Looks like the author just dumps ActivityPub IDs into twtxt. I think this used to work in the past, but the corresponding spec (https://twtxt.dev/exts/hash-tag.html) has been deprecated and jenny doesn’t support – actually, jenny never supported that.

jenny can only group threads by exactly one criterium (because it writes a Message-ID into the mail file) and that’s the regular twt hash. So, anything else, like people doing “#CoolTopic”, isn’t possible.

I’m still making progress with the Emacs client. I’m proud to say that the code that is responsible for reading the feeds is almost finished, including: Twt Hash Extension, Twt Subject Extension, Multiline Extension and Metadata Extension. I’m fine-tuning some tests and will soon do the first buffer that displays the twts.

@bmallred@staystrong.run did you rotate your twtxt file or something happened to your twts? 🤔 asking just in case…

hmm… apparently the invalid twts are the latest ones I’d posted from Timeline but highly probably because I’d tried to restore them manually, after unintentionally overriding my twtxt file with one that was out of date 🤦

Want this API for Goryon or just Goryon with support to just twtxt.txt. I can’t read timeline without visible replies and missing twts

Shi… I forgot to pull my twtxt file before twtin’ … let me see if I can recover them lost timeline twts.

Showing my nephew around linux… and what’s a better example of text editing in terminal than an actual twt? eh? 😆

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

@doesnm@doesnm.p.psf.lt I sent that mention manually for a demonstration as mentioned in the previous twt. Used the curl method.

@prologic@twtxt.net There’s always my log.html page if it helps… and while we’re still at it here’s the other twt #z2ymlkq for reference ;)

@prologic@twtxt.net I bet our twts are already being fed to circuit monsters… Remember the other day when I’d snapped out about some nonsense, being an A-Hole and what not? I’ve seen an AI company employee lurking around with not much interaction (if I’m not mistaken), so my mind went on auto-pilot mode thinking “This !#@%$ must be feeding us to the circuit peggy monster!! Arrr 😤” 🤣🤣🤣 but then again, one shouldn’t judge a book by it’s cover (or an employee by his title) right?

@quark@ferengi.one What would happen if I replayed to this twt from the future, when I’m still in it’s relative past? 🤔

I wish I could view source twts like this to know if the root was not found and this was actually in reply to something i cant see.

Image

I ended up deploying an OpenGist instead! unlike MicroBin, the whole things went smoother than posting a twt 😆

I guess I should setup some kind of past-bin or something, I bet somebody’s already angry about them last couple of long twts 😅 Sorry, not sorry! but I’ll try to fix that.

@aelaraji@aelaraji.com You could use https://lyse.isobeef.org/tmp/twthash.py to generate twt hashes. I cobbled that together in order to generate test data for my client.

@bender@twtxt.net highly probably, unless I learn go and implement it myself (or someone else more capable does) … but I’m so lazy I’d just copy them from twtxt.net and call it a day xD and yeah, it’s kinda rough the way things are…

• I don’t see a way to follow others, all I can do is go to the /feeds URI for a list of the server’s users/feeds.
  
• I still couldn’t figure out how to get a direct link to a user’s twtxt file, curling /feeds/usernick spits out a list of the user usernick twts, so I guess you could use that to follow them.
  
• no way to add in your # nick = usernick / # url = proto://domain.ltd/path/to/twtxt.txt …etc. Probably because that wasn’t part of the spec back then?
  

So yeah, it would make for a nice project while learning Go. :P

I’m getting way too comfortable with editing twts and fixing Eff’ ups… I gotta stop auto-syncing my twtxt file, at least I’ll have a breathing room for quick fixes when needed. I know, Michael Lucas might not approve of this but, I wouldn’t want the @yarn_police@twtxt.net in the middle of the night, right?

Ok, I’ve restored the misplaced twts … let’s just hope I didn’t make things worst xD

@bender@twtxt.net Haha! I assume you can’t see the original twt, let me quote for you so you know what I’m responding to:

2024-11-20T07:56:00-06:00 (#gjhq2xq) 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 ;)
source: eaplme’s twtxt file.

@eapl.me@eapl.me adding public $timestamp; to the class Twt in libs/twtxt.php (line 25) fixed that for me but probably broken something else 😅 …

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

@bender@twtxt.net @movq@www.uninformativ.de exactly! 😂 I accidentally duplicated a twt and deleted it as fast as I can, hoping nobody pulled the feed by then.

@bender@twtxt.net > which feed of his are you following? the .mx or the .me one? I was replaying to THIS TWT

@bender@twtxt.net So turns out something is setting my HashingURI to the value {{ .Profile.URI }} and that is making my hashes wrong so it cannot delete or edit twts.

So helpful 😮‍💨

Error: Error deleting last twt

Can I edit this twt?

@lyse@lyse.isobeef.org

Regarding section 4 about feed discovery: Yeah, non-HTTP transport protocols are an issue as they do not have User-Agent headers. How exactly do you envision the discovery_url to work, though?

This is from a twt of mine from January 2022:

https://www.uninformativ.de/files/twtxt/2022%2D01%2D22%2D%2Dfollow%2Dendpoint.md

(This idea gets lost all the time, so I put it into a file now. 😅)

Not sure if this is what @eapl.me@eapl.me had in mind, obviously.

Thank you, @eapl.me@eapl.me! No need to apologize in the introduction, all good. :-)

Section 3: I’m a bit on the fence regarding documenting the HTTP caching headers. It’s a very general HTTP thing, so there is nothing special about them for twtxt. No need for the Twtxt Specification to actually redo it. But on the other hand, a short hint could certainly help client developers and feed authors. Maybe it’s thanks to my distro’s Ngninx maintainer, but I did not configure anything for the Last-Modified and ETag headers to be included in the response, the web server just already did it automatically.

The more that I think about it while typing this reply, the more I think your recommendation suggestion is actually really great. It will definitely beneficial for client developers. In almost all client implementation cases I’d say one has to actually do something specifically in the code to send the If-Modified-Since and/or If-None-Match request headers. There is no magic that will do it automatically, as one has to combine data from the last response with the new request.

But I also came across feeds that serve zero response headers that make caching possible at all. So, an explicit recommendation enables feed authors to check their server setups. Yeah, let’s absolutely do this! :-)

Regarding section 4 about feed discovery: Yeah, non-HTTP transport protocols are an issue as they do not have User-Agent headers. How exactly do you envision the discovery_url to work, though? I wouldn’t limit the transports to HTTP(S) in the Twtxt Specification, though. It’s up to the client to decide which protocols it wants to support.

Since I currently rely on buckket’s twtxt client to fetch the feeds, I can only follow http(s):// (and file://) feeds. But in tt2 I will certainly add some gopher:// and gemini:// at some point in time.

Some time ago, @movq@www.uninformativ.de found out that some Gopher/Gemini users prefer to just get an e-mail from people following them: https://twtxt.net/twt/dikni6q So, it might not even be something to be solved as there is no problem in the first place.

Section 5 on protocol support: You’re right, announcing the different transports in the url metadata would certainly help. :-)

Section 7 on emojis: Your idea of TUI/CLI avatars is really intriguing I have to say. Maybe I will pick this up in tt2 some day. :-)

@eapl.me@eapl.me Neat.

So for twt metadata the lextwt parser currently supports values in the form [key=value]

https://git.mills.io/yarnsocial/go-lextwt/src/branch/main/parser_test.go#L692-L698

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

Righto, @eapl.me@eapl.me, ta for the writeup. Here we go. :-)

Metadata on individual twts are too much for me. I do like the simplicity of the current spec. But I understand where you’re coming from.

Numbering twts in a feed is basically the attempt of generating message IDs. It’s an interesting idea, but I reckon it is not even needed. I’d simply use location based addressing (feed URL + ‘#’ + timestamp) instead of content addressing. If one really wanted to, one could hash the feed URL and timestamp, but the raw form would actually improve disoverability and would not even require a richer client. But the majority of twtxt users in the last poll wanted to stick with content addressing.

yarnd actually sends If-Modified-Since request headers. Not only can I observe heaps of 304 responses for yarnds in my access log, but in Cache.FetchFeeds(…) we can actually see If-Modified-Since being deployed when the feed has been retrieved with a Last-Modified response header before: https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/cache.go#L1278

Turns out etags with If-None-Match are only supported when yarnd serves avatars (https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/handlers.go#L158) and media uploads (https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/media_handlers.go#L71). However, it ignores possible etags when fetching feeds.

I don’t understand how the discovery URLs should work to replace the User-Agent header in HTTP(S) requests. Do you mind to elaborate?

Different protocols are basically just a client thing.

I reckon it’s best to just avoid mixing several languages in one feed in the first place. Personally, I find it okay to occasionally write messages in other languages, but if that happens on a more regularly basis, I’d definitely create a different feed for other languages.

Isn’t the emoji thing “just” a client feature? So, feed do not even have to state any emojis. As a user I’d configure my client to use a certain symbol for feed ABC. Currently, I can do a similar thing in tt where I assign colors to feeds. On the other hand, what if a user wants to control what symbol should be displayed, similar to the feed’s nick? Hmm. But still, my terminal font doesn’t even render most of emojis. So, Unicode boxes everywhere. This makes me think it should actually be a only client feature.

Oh! a new feed to follow! Welcome in @wbknl@twtxt.net 👋 looking forward to reading your twts!