> 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. 🤦
> 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
> 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 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 had in mind, obviously.
> 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 had in mind, obviously.
> 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 had in mind, obviously.
> 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 had in mind, obviously.
How am I suppose to know whether stuff like this (_sound serious_) is for realz or not? 😅
How am I suppose to know whether stuff like this (_sound serious_) is for realz or not? 😅
Hmmm 🧐
Hmmm 🧐
Emoji not showing
Quando o gov corta na educação, não é porque não sabe gerir a sociedade.
Quando o gov corta nos programas sociais, não é porque não reconhece o seu papel social.
É agenda: este gov de direita, tal como qualquer outro, tem como base programática o desmantelamento do estado social e da coisa pública. E nisso tem sido extremamente eficaz e competente.
Uma esquerda que denuncia a suposta incompetência ou burrice das pessoas no poder dá-lhes o crédito de estarem empenhados numa sociedade melhor pra todes, e que ao falhar nisso é uma questão de incompetência.
E quando essa denúncia é feita através de comentários sarcásticos e apontamentos de "hipocrisia", servindo mais para afirmar superioridade intelectual do que realmente denunciar e avançar alternativas, é uma trágica forma de clicktivismo que continua extremamente em voga -- e a direita agradece.
tl;dr: tratar as medidas opressivas/autoritárias/securitárias de qualquer direita como fruto de burrice ou incompetência não é só um erro, é alimentar e até legitimar o seu discurso
Quando o gov corta na educação, não é porque não sabe gerir a sociedade.
Quando o gov corta nos programas sociais, não é porque não reconhece o seu papel social.
É agenda: este gov de direita, tal como qualquer outro, tem como base programática o desmantelamento do estado social e da coisa pública. E nisso tem sido extremamente eficaz e competente.
Uma esquerda que denuncia a suposta incompetência ou burrice das pessoas no poder dá-lhes o crédito de estarem empenhados numa sociedade melhor pra todes, e que ao falhar nisso é uma questão de incompetência.
E quando essa denúncia é feita através de comentários sarcásticos e apontamentos de "hipocrisia", servindo mais para afirmar superioridade intelectual do que realmente denunciar e avançar alternativas, é uma trágica forma de clicktivismo que continua extremamente em voga -- e a direita agradece.
tl;dr: tratar as medidas opressivas/autoritárias/securitárias de qualquer direita como fruto de burrice ou incompetência não é só um erro, é alimentar e até legitimar o seu discurso
/https://baldo.cat/media/photos/IMG_2562.jpeg) #catsoftwtxt
#catsoftwtxt
#catsoftwtxt
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 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. :-)
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
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
hot, legs were tight, but felt alright i guess.
#running
hot, legs were tight, but felt alright i guess.
#running
hot, legs were tight, but felt alright i guess.
#running
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
 if something is NSFW2. 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?=
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
 if something is NSFW2. 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?=
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
 if something is NSFW2. 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?=
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
 if something is NSFW2. 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?=
> 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 said earlier though, sometimes he and @movq "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._
> 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 said earlier though, sometimes he and @movq "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._
> 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.
> 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.