@bender@twtxt.net Ull Twt to find the references later. But my memory is quite good 🤣
@prologic@twtxt.net sorry, tried looking for the points you mentioned, but couldn’t find them. Got a link?
@bender@twtxt.net Fair point, could be. I probably have to implement it first or create some kind of a mockup to spare me the effort of some feature that I rip out again. :-)
@xuu@txt.sour.is Yep!
@movq@www.uninformativ.de Riiiight, I now remember reading that a long time ago. :-)
@bender@twtxt.net I now read the German Wikipedia article on fog. These are some really beautiful pictures:
- https://upload.wikimedia.org/wikipedia/commons/a/a9/Nebelbank_in_der_W%C3%BCste_Namib_bei_Aus_%282018%29.jpg
- https://upload.wikimedia.org/wikipedia/commons/1/17/Space_Shuttle_Challenger_moving_through_fog.jpg
- https://upload.wikimedia.org/wikipedia/commons/9/96/Fog_Bow_%2819440790708%29.jpg
- https://upload.wikimedia.org/wikipedia/commons/a/ac/360_degrees_fogbow.jpg
To @anth@a.9srv.net’s points, I think this should be written as “Client recommendations” and “Serve recommendations”. Separate from the “Twtxt format” spec.
HTTP caching headers
Yes, absolutely, this should be mentioned in the spec. I’m guilty – when I first wrote my twtxt client, I forgot that If-Modified-Since
is a thing. 🤦
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 thediscovery_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.
@bender@twtxt.net Agreed 👍
@lyse@lyse.isobeef.org agree on the HTTP stuff. I mean we could mention that for optimization see RFC yadda yadda should be followed for caching. but not have it part of the spec proper.
@prologic@twtxt.net lies, and scams aside, there is plenty of need in the world. Yet, you can’t help everyone. Best way to do it is to donate to a worthy cause, and ignore one offs.
@bender@twtxt.net I’ve worked with this guy before. Paid him to do some freelance work. Not very good IMO. So haven’t hired him ever again. But he keeps saying hi every now and then on Signal. And then every few months or so asking stuff like this ☝️ – Last time it was money for private school fees for his child.
How am I suppose to know whether stuff like this (sound serious) is for realz or not? 😅
@prologic@twtxt.net “here, have 2 rupees.”
I need money for my mother’s heart surgery, there is a shortfall of about 2 million rupiah from a total of 40 million, can you help me with any amount?
Hmmm 🧐
😜
😜😜😜 well, now I can. This is beyond weird.
@xuu@txt.sour.is that’s on iOS? I can’t (running 18.1).
First one on the third row, for example. There are more, though.
@prologic@twtxt.net how could I show you what I can’t type? 😂 Let’s see, a second.
@bender@twtxt.net such as?
I have noticed that Yarn (here) will not take some emoji. At least, will not take some under iOS.
@lyse@lyse.isobeef.org precisely. The fog itself doesn’t smell. It simply carries the smell of its surroundings. Find what those surroundings are, and the credit will go to the right thing. 😊
@lyse@lyse.isobeef.org I think it would make the interface look too busy, I would pass on that one.
@sorenpeter@darch.dk Section 7 on emojis: Exactly that, it’s an avatar for text interfaces. The metadata name needs tweaking, but that’s a cool idea. If I implemented this in my client, I’d make the text avatar overridable by the user, though. Otherwise I’d probably only see boxes for everbody in my terminal. :-D
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. :-)
Perfect, @eapl.me@eapl.me, it’s fixed again. In fact this editor seems to support the Unicode line separator character all too well, otherwise it would not have replaced it in the first place. :-D Time to switch to a more unintelligent editor. ;-)
Thanks, @bender@twtxt.net. I try to.
I haven’t noticed any smell of fog, @bender@twtxt.net. Might @nff@www.noizhardware.com’s experience stem from a similar phenomenon that creates a lovely smell after a good, air-cleaning rain shower?
@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
@sorenpeter@darch.dk on 4 for gemini if your TLS client certificate contains your nick@host could that work for discovery?
@nff@www.noizhardware.com it is actually quite bad, so what you are smelling ain’t fog.
the smell of fog is soo gud <3
I realise now that the referred post might just be fiction. I am slow Ferengi these days. LOL.
@wbknl@twtxt.net are you still in Russia? It could be hard mailing anything to there these days. I read your “russia is eternally cold”, and became curious. Patagonia is the only place I know on South America that it has rounded mountains, though they can be anywhere. Originally from Chile, or Argentina? My curiosity doesn’t need feeding, by the way. It’s all good if it doesn’t. :-)
This morning (and a little bit of the afternoon) the idea of having a full referenced archive of twtxts on the web has consumed me a bit. I am talking about something similar to the email archives one see online, but for twtxts, and a more personal level. Such archive would be available, even if the involved feeds are long gone, because feeds will be treated as received emails.
@eapl.me@eapl.me here are my replies (somewhat similar to Lyse’s and James’)
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 NSFWIDs 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.
Caching, Yes all good ideas, but that is more a task for the clients not the serving of the twtxt.txt files.
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.
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
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.
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?
@eapl.me@eapl.me Regarding supporting languages:
That said, coming from platforms like X and Masto, where switching languages is easy, I naturally read content and write into my timeline in at least three languages. Changing my “account” is not a simple as switching languages, and in those platforms have another meaning (“I’m a different person”). Supporting that would be beneficial for some, though I’m not sure how many would use it.
I think this is more of a client concern in my opinion. Like @lyse@lyse.isobeef.org said earlier though, sometimes he and @movq@www.uninformativ.de “Twt” in German. I don’t (nor anyone else I’m aware of) have a problem with this. It seems to be that a “client” could detect this and deal with this appropriately or give a user appropriately controls.
For me (_personally__ I’ve never found it a problem. I use extensions like “Simple Translate” anyway, so it doesn’t matter a great deal to me.
@eapl.me@eapl.me Just responding to some of your specific ideations here:
Sure! From my research, Gemini (and likely Gopher as well) don’t have a similar header, so if a client is using those protocols, they won’t be able to inform your server.
So, it’s worth considering, would twtxt 2.0 only support HTTP/S?
I’m not sure how to standardize “Discovery” across different protocols for serving feeds, HTTP, Gopher, Gemini, etc. beyond what you initially suggested. But here’s the thing, the User-Agent
HTTP Header isn’t the only aspect to “discovery”. Discovery in practise is more of an organic property of @-mentions across feeds in the first place, something that crawlers take advantage of.
@slashdot@feeds.twtxt.net Oh come one?! Web5?! Since when was this even thing?! 😱 🤦♂️ I could grample with Web 1.0, Web 2.0 and even Web 3.0 (to a container degre), but Web 4.0 and Web 5.0 ?! Come on?! 😱 Get the fuck out! (GTFO) 😠
Thanks @lyse@lyse.isobeef.org! I’m replying here https://text.eapl.mx/reply-to-lyse-about-twtxt
Jack Dorsey’s Block Scraps ‘Web5’ Project
Block will abandon development of its Web5 decentralized internet project and reduce investment in music streaming service Tidal to focus on bitcoin mining hardware and self-custody wallets, the payments company announced in its third-quarter letter to shareholders. The Jack Dorsey-led firm cited strong market demand for its bitcoin mining products and Bitkey wallet as key drivers behind the st … ⌘ Read more
This is beautiful and made my day
@lyse@lyse.isobeef.org you sure are a crafty young man!
@bender@twtxt.net Ohhh, nice! I tried to learn Morse code a while back (well, 11 years ago, apparently), but never got very good at it. 😢 Ultimately, I didn’t have a real-world application for it. 🫤