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.
Shelf sitting on the drill press table before installing it between the posts of the standWhen I glued the shelf between the posts of the stand, I tightened the long clamp too hard, ripping the back panel and shelf board apart. So, I had to reglue them. :-)
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#L1278Turns 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.
Btw. if you blindly run the command again in a few days, your query might match new feeds that are not included in today's list. Hence, some accounts might be dropped without a warning. But then, they probably don't care.
https://youtu.be/pZonZntFU7Y
https://youtu.be/pZonZntFU7Y
My father was a professional radio-telegraphist for many years, until his retirement at 67 years old.
first four intervals were good. needed more time to rest i think between the 400m intervals because the humidity was tough again. stopped after the fourth because it was so bad. fema out in full force on the trail, too.
#running
first four intervals were good. needed more time to rest i think between the 400m intervals because the humidity was tough again. stopped after the fourth because it was so bad. fema out in full force on the trail, too.
#running
first four intervals were good. needed more time to rest i think between the 400m intervals because the humidity was tough again. stopped after the fourth because it was so bad. fema out in full force on the trail, too.
#running
Knowing how many other things hams can get into, I doubt there is even one using twtxt. You would know, right @prologic ?
It’s too early to tell, but it’s not looking good. We don’t have an orange clown (yet), but the country is deeply divided. Right and far-right parties are on the rise.
😐
It’s too early to tell, but it’s not looking good. We don’t have an orange clown (yet), but the country is deeply divided. Right and far-right parties are on the rise.
😐
It’s too early to tell, but it’s not looking good. We don’t have an orange clown (yet), but the country is deeply divided. Right and far-right parties are on the rise.
😐
It’s too early to tell, but it’s not looking good. We don’t have an orange clown (yet), but the country is deeply divided. Right and far-right parties are on the rise.
😐
$ ./tools/inactive_users.sh 730
@thgie last seen 732 days ago
@will last seen 740 days ago
@shaneflores last seen 752 days ago
@magnus last seen 757 days ago
@nickmellor last seen 757 days ago
@birb last seen 763 days ago
@screem last seen 772 days ago
@servusdei last seen 774 days ago
@alex last seen 790 days ago
@andreottica last seen 801 days ago
@fox last seen 822 days ago
@anx last seen 829 days ago
@olav last seen 855 days ago
@caesar last seen 866 days ago
@jim last seen 869 days ago
@rell last seen 882 days ago
@readfog last seen 886 days ago
If anyone on this lists sees this post and wishes to preserve their feed/account for some reason (_beyonds backups I maintain_), please login at least once over the next coming weeks to get off this list. I will re-run this tool again, and then nuke blindly anything that matches >730 days of inactivity.
$ ./tools/inactive_users.sh 730
@thgie last seen 732 days ago
@will last seen 740 days ago
@shaneflores last seen 752 days ago
@magnus last seen 757 days ago
@nickmellor last seen 757 days ago
@birb last seen 763 days ago
@screem last seen 772 days ago
@servusdei last seen 774 days ago
@alex last seen 790 days ago
@andreottica last seen 801 days ago
@fox last seen 822 days ago
@anx last seen 829 days ago
@olav last seen 855 days ago
@caesar last seen 866 days ago
@jim last seen 869 days ago
@rell last seen 882 days ago
@readfog last seen 886 days ago
If anyone on this lists sees this post and wishes to preserve their feed/account for some reason (_beyonds backups I maintain_), please login at least once over the next coming weeks to get off this list. I will re-run this tool again, and then nuke blindly anything that matches >730 days of inactivity.