(So I will most likely not be joining the call)
(So I will most likely not be joining the call)
(So I will most likely not be joining the call)
(I know, the formatting is messed up;)
(I know, the formatting is messed up;)
(I know, the formatting is messed up;)
(I know, the formatting is messed up;)
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?=
(#<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?
(#<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?
(#<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?
(#<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?
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.=
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.=
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.=
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.=
0. 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.1. 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).
3. Do we need more commandments?
0. 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.1. 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).
3. Do we need more commandments?
0. 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.1. 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).
3. Do we need more commandments?
0. 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.1. 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).
3. Do we need more commandments?
https://www.youtube.com/watch?v=CsM39SpRik8
https://www.youtube.com/watch?v=CsM39SpRik8
https://www.youtube.com/watch?v=CsM39SpRik8
https://www.youtube.com/watch?v=CsM39SpRik8
> 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
> 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
> 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
> 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
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
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
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
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