# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 1000
# self = https://watcher.sour.is?uri=http://darch.dk/twtxt.txt&offset=700
# next = https://watcher.sour.is?uri=http://darch.dk/twtxt.txt&offset=800
# prev = https://watcher.sour.is?uri=http://darch.dk/twtxt.txt&offset=600
@2024-10-08T19:36:38-07:00 Thanks for the followup. I agrees with most of it - especially:
> 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
@2024-10-08T19:36:38-07:00 Thanks for the followup. I agrees with most of it - especially:
> 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
@2024-10-08T19:36:38-07:00 Thanks for the followup. I agrees with most of it - especially:
> 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
Thanks @david, good to know, but we need to agree on what character we use, otherwise the hashes will not be the same:)
Thanks @david, good to know, but we need to agree on what character we use, otherwise the hashes will not be the same:)
Thanks @david, good to know, but we need to agree on what character we use, otherwise the hashes will not be the same:)
Thanks @david, good to know, but we need to agree on what character we use, otherwise the hashes will not be the same:)
@prologic Regarding the new way of generating twt-hashes, to me it makes more sense to use tabs as separator instead of spaces, since the you can just copy/past a line directly from a twtxt-file that already go a tab between timestamp and message. But tabs might be hard to "type" when you are in a terminal, since it will activate autocomplete...🤔
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
@prologic Regarding the new way of generating twt-hashes, to me it makes more sense to use tabs as separator instead of spaces, since the you can just copy/past a line directly from a twtxt-file that already go a tab between timestamp and message. But tabs might be hard to "type" when you are in a terminal, since it will activate autocomplete...🤔
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
@prologic Regarding the new way of generating twt-hashes, to me it makes more sense to use tabs as separator instead of spaces, since the you can just copy/past a line directly from a twtxt-file that already go a tab between timestamp and message. But tabs might be hard to "type" when you are in a terminal, since it will activate autocomplete...🤔
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
@prologic Regarding the new way of generating twt-hashes, to me it makes more sense to use tabs as separator instead of spaces, since the you can just copy/past a line directly from a twtxt-file that already go a tab between timestamp and message. But tabs might be hard to "type" when you are in a terminal, since it will activate autocomplete...🤔
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
@prologic YES James, it should be up to the client to deal with changes like edits and deletions. And putting this load on the clients, location-addressing with make this a lot easier since what is says it: Look in this file at this timestamp, did anything change or went missing? (And then threading will not break;)
@prologic YES James, it should be up to the client to deal with changes like edits and deletions. And putting this load on the clients, location-addressing with make this a lot easier since what is says it: Look in this file at this timestamp, did anything change or went missing? (And then threading will not break;)
@prologic YES James, it should be up to the client to deal with changes like edits and deletions. And putting this load on the clients, location-addressing with make this a lot easier since what is says it: Look in this file at this timestamp, did anything change or went missing? (And then threading will not break;)
@prologic YES James, it should be up to the client to deal with changes like edits and deletions. And putting this load on the clients, location-addressing with make this a lot easier since what is says it: Look in this file at this timestamp, did anything change or went missing? (And then threading will not break;)
why can we both have a format that you can write by hand and better clients?
why can we both have a format that you can write by hand and better clients?
why can we both have a format that you can write by hand and better clients?
why can we both have a format that you can write by hand and better clients?
@bender doesn't work if you are not logged in at twtxt.net. Even if I use the image URL from the raw twtxt it's still a blur.
What does this screenshot show? The resolution it too low for reading the text...
(#2024-09-24T12:53:35Z) What does this screenshot show? The resolution it too low for reading the text...
(#2024-09-24T12:53:35Z) What does this screenshot show? The resolution it too low for reading the text...
(#2024-09-24T12:53:35Z) What does this screenshot show? The resolution it too low for reading the text...
(#2024-09-24T12:53:35Z) What does this screenshot show? The resolution it too low for reading the text...
(#2024-09-24T12:45:54Z) @prologic I'm not really buying this one about readability. It's easy to recognize that this is a URL and a date, so you skim over it like you would we mentions and markdown links and images. If you are not suppose to read the raw file, then we might a well jam everything into JSON like mastodon
(#2024-09-24T12:45:54Z) @prologic I'm not really buying this one about readability. It's easy to recognize that this is a URL and a date, so you skim over it like you would we mentions and markdown links and images. If you are not suppose to read the raw file, then we might a well jam everything into JSON like mastodon
(#2024-09-24T12:45:54Z) @prologic I'm not really buying this one about readability. It's easy to recognize that this is a URL and a date, so you skim over it like you would we mentions and markdown links and images. If you are not suppose to read the raw file, then we might a well jam everything into JSON like mastodon
(#2024-09-24T12:45:54Z) @prologic I'm not really buying this one about readability. It's easy to recognize that this is a URL and a date, so you skim over it like you would we mentions and markdown links and images. If you are not suppose to read the raw file, then we might a well jam everything into JSON like mastodon
@prologic I'm not really buying this one about readability. It's easy to recognize that this is a URL and a date, so you skim over it like you would we mentions and markdown links and images. If you are not suppose to read the raw file, then we might a well jam everything into JSON like mastodon
(#2024-09-24T12:44:35Z) There is a increase in space/memory for sure. But calculating the hashes also takes up CPU. I'm not good with that kind of math, but it's a tradeoff either way.
(#2024-09-24T12:44:35Z)\tThere is a increase in space/memory for sure. But calculating the hashes also takes up CPU. I'm not good with that kind of math, but it's a tradeoff either way.
(#2024-09-24T12:44:35Z) There is a increase in space/memory for sure. But calculating the hashes also takes up CPU. I'm not good with that kind of math, but it's a tradeoff either way.
There is a increase in space/memory for sure. But calculating the hashes also takes up CPU. I'm not good with that kind of math, but it's a tradeoff either way.
(#2024-09-24T12:44:35Z) There is a increase in space/memory for sure. But calculating the hashes also takes up CPU. I'm not good with that kind of math, but it's a tradeoff either way.
(#2024-09-24T12:44:35Z) There is a increase in space/memory for sure. But calculating the hashes also takes up CPU. I'm not good with that kind of math, but it's a tradeoff either way.
(#2024-09-24T12:39:32Z) @prologic It might be simple for you to run echo -e "\\t\\t" | sha256sum | base64, but for people who are not comfortable in a terminal and got their dev env set up, then that is magic, compared to the simplicity of just copy/pasting what you see in a textfile into another textfile -- Basically what @movq also said. I'm also on team extreme minimalism, otherwise we could just use mastodon etc. Replacing line-breaks with a tab would also make it easier to handwrite your twtxt. You don't have to hardwrite it, but at least you should have the option to. Just as i do with all my HTML and CSS.
(#2024-09-24T12:39:32Z) @prologic It might be simple for you to run echo -e "\t\t" | sha256sum | base64, but for people who are not comfortable in a terminal and got their dev env set up, then that is magic, compared to the simplicity of just copy/pasting what you see in a textfile into another textfile -- Basically what @movq also said. I'm also on team extreme minimalism, otherwise we could just use mastodon etc. Replacing line-breaks with a tab would also make it easier to handwrite your twtxt. You don't have to hardwrite it, but at least you should have the option to. Just as i do with all my HTML and CSS.
(#2024-09-24T12:39:32Z) @prologic) @prologic It might be simple for you to run echo -e "\\t\\t" | sha256sum | base64, but for people who are not comfortable in a terminal and got their dev env set up, then that is magic, compared to the simplicity of just copy/pasting what you see in a textfile into another textfile -- Basically what @movq also said. I'm also on team extreme minimalism, otherwise we could just use mastodon etc. Replacing line-breaks with a tab would also make it easier to handwrite your twtxt. You don't have to hardwrite it, but at least you should have the option to. Just as i do with all my HTML and CSS.
(#2024-09-24T12:39:32Z) @prologic It might be simple for you to run echo -e "\t\t" | sha256sum | base64, but for people who are not comfortable in a terminal and got their dev env set up, then that is magic, compared to the simplicity of just copy/pasting what you see in a textfile into another textfile -- Basically what @movq also said. I'm also on team extreme minimalism, otherwise we could just use mastodon etc. Replacing line-breaks with a tab would also make it easier to handwrite your twtxt. You don't have to hardwrite it, but at least you should have the option to. Just as i do with all my HTML and CSS.
(#2024-09-24T12:39:32Z) @prologic It might be simple for you to run echo -e "\t\t" | sha256sum | base64, but for people who are not comfortable in a terminal and got their dev env set up, then that is magic, compared to the simplicity of just copy/pasting what you see in a textfile into another textfile -- Basically what @movq also said. I'm also on team extreme minimalism, otherwise we could just use mastodon etc. Replacing line-breaks with a tab would also make it easier to handwrite your twtxt. You don't have to hardwrite it, but at least you should have the option to. Just as i do with all my HTML and CSS.
(#2024-09-24T12:39:32Z) @prologic It might be simple for you to run echo -e "\t\t" | sha256sum | base64, but for people who are not comfortable in a terminal and got their dev env set up, then that is magic, compared to the simplicity of just copy/pasting what you see in a textfile into another textfile -- Basically what @movq also said. I'm also on team extreme minimalism, otherwise we could just use mastodon etc. Replacing line-breaks with a tab would also make it easier to handwrite your twtxt. You don't have to hardwrite it, but at least you should have the option to. Just as i do with all my HTML and CSS.
@prologic It might be simple for you to run echo -e "\\t\\t" | sha256sum | base64, but for people who are not comfortable in a terminal and got their dev env set up, then that is magic, compared to the simplicity of just copy/pasting what you see in a textfile into another textfile -- Basically what @movq also said. I'm also on team extreme minimalism, otherwise we could just use mastodon etc. Replacing line-breaks with a tab would also make it easier to handwrite your twtxt. You don't have to hardwrite it, but at least you should have the option to. Just as i do with all my HTML and CSS.
(#2024-09-24T12:34:31Z) WebMentions does would work if we agreed to implement it correctly. I never figured out how yarnd's WebMentions work, so I decide to make my own, which I'm the only one using...
I had a look at WebSub, witch looks way more complex than WebMentions, and seem to need a lot more overhead. We don't need near realtime. We just need a way to notify someone that someone they don't know about mentioned or replied to their post.
(#2024-09-24T12:34:31Z) WebMentions does would work if we agreed to implement it correctly. I never figured out how yarnd's WebMentions work, so I decide to make my own, which I'm the only one using...
I had a look at WebSub, witch looks way more complex than WebMentions, and seem to need a lot more overhead. We don't need near realtime. We just need a way to notify someone that someone they don't know about mentioned or replied to their post.
WebMentions does would work if we decince to implement it correctly. I never figured out how yarnd's WebMentions work, so I decide to make my own, with I'm the only one using...
I had a look at WebSub, witch is way more complex than WebMentions, and seem to need a lot more overhead. We don't need near realtime. We just need a way to notify someone that someone they don't know about mentioned or replied to their post.
WebMentions does would work if we agreed to implement it correctly. I never figured out how yarnd's WebMentions work, so I decide to make my own, which I'm the only one using...
I had a look at WebSub, witch looks way more complex than WebMentions, and seem to need a lot more overhead. We don't need near realtime. We just need a way to notify someone that someone they don't know about mentioned or replied to their post.
WebMentions does would work if we agreed to implement it correctly. I never figured out how yarnd's WebMentions work, so I decide to make my own, with I'm the only one using...
I had a look at WebSub, witch is way more complex than WebMentions, and seem to need a lot more overhead. We don't need near realtime. We just need a way to notify someone that someone they don't know about mentioned or replied to their post.
(#2024-09-24T12:34:31Z) WebMentions does would work if we agreed to implement it correctly. I never figured out how yarnd's WebMentions work, so I decide to make my own, which I'm the only one using...
I had a look at WebSub, witch looks way more complex than WebMentions, and seem to need a lot more overhead. We don't need near realtime. We just need a way to notify someone that someone they don't know about mentioned or replied to their post.
(#2024-09-24T12:34:31Z) WebMentions does would work if we agreed to implement it correctly. I never figured out how yarnd's WebMentions work, so I decide to make my own, which I'm the only one using...
I had a look at WebSub, witch looks way more complex than WebMentions, and seem to need a lot more overhead. We don't need near realtime. We just need a way to notify someone that someone they don't know about mentioned or replied to their post.
Some more arguments for a local-based treading model over a content-based one:
1. The format: (#<DATE URL>) or (@<DATE URL>) both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash) and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.
2. Having something like (#<DATE URL>) will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash. This will also make it possible to make 3th part twt-mentions services.
3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don't follow.
Some more arguments for a local-based treading model over a content-based one:
1. The format: (#<DATE URL>) or (@<DATE URL>) both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash) and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.
2. Having something like (#<DATE URL>) will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash. This will also make it possible to make 3th part twt-mentions services.
3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don't follow.
Some more arguments for a local-based treading model over a content-based one:
1. The format: (#<DATE URL>) or (@<DATE URL>) both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash) and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.
2. Having something like (#<DATE URL>) will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash. This will also make it possible to make 3th part twt-mentions services.
3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don't follow.
Some more arguments for a local-based treading model over a content-based one:
1. The format: (#<DATE URL>) or (@<DATE URL>) both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash) and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.
2. Having something like (#<DATE URL>) will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash. This will also make it possible to make 3th part twt-mentions services.
3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don't follow.
@movq I cases of these kind of "abuse" of social trust. Then I think people should just delete their replies, unfollow the troll and leave them to shouting in the void. This is a inter-social issue, not a technical issue. Anything can be spoofed. We are not building a banking app, we are just having conversation and if trust are broken then communication breaks down. These edge-cases are all very hypothetical and not something I think we need to solve with technology.
@movq I cases of these kind of "abuse" of social trust. Then I think people should just delete their replies, unfollow the troll and leave them to shouting in the void. This is a inter-social issue, not a technical issue. Anything can be spoofed. We are not building a banking app, we are just having conversation and if trust are broken then communication breaks down. These edge-cases are all very hypothetical and not something I think we need to solve with technology.
@movq I cases of these kind of "abuse" of social trust. Then I think people should just delete their replies, unfollow the troll and leave them to shouting in the void. This is a inter-social issue, not a technical issue. Anything can be spoofed. We are not building a banking app, we are just having conversation and if trust are broken then communication breaks down. These edge-cases are all very hypothetical and not something I think we need to solve with technology.
@movq I cases of these kind of "abuse" of social trust. Then I think people should just delete their replies, unfollow the troll and leave them to shouting in the void. This is a inter-social issue, not a technical issue. Anything can be spoofed. We are not building a banking app, we are just having conversation and if trust are broken then communication breaks down. These edge-cases are all very hypothetical and not something I think we need to solve with technology.
Been thinking about it for the last couple of days and I would say we can make do with the shorter (#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?
Been thinking about it for the last couple of days and I would say we can make do with the shorter (#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?
Been thinking about it for the last couple of days and I would say we can make do with the shorter (#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?
Been thinking about it for the last couple of days and I would say we can make do with the shorter (#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?
@quark It does not. That is why I'm advocating for not using hashes for treads, but a simpler link-back scheme.
@quark It does not. That is why I'm advocating for not using hashes for treads, but a simpler link-back scheme.
@quark It does not. That is why I'm advocating for not using hashes for treads, but a simpler link-back scheme.
@quark It does not. That is why I'm advocating for not using hashes for treads, but a simpler link-back scheme.
@prologic you will always be replying to OP - that is what the twthash is a shorthand for, it it not?!
@prologic you will always be replying to OP - that is what the twthash is a shorthand for, it it not?!
@prologic you will always be replying to OP - that is what the twthash is a shorthand for, it it not?!
@prologic you will always be replying to OP - that is what the twthash is a shorthand for, it it not?!
no my fault your client can't handle a little editing ;)
no my fault your client can't handle a little editing ;)
no my fault your client can't handle a little editing ;)
no my fault your client can't handle a little editing ;)
@movq I'm glad you like it. A mention (@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person.
@movq I'm glad you like it. A mention (@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions:
(#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@movq I'm glad you like it. A mention (@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person.
@movq I'm glad you like it. A mention (@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@movq I'm glad you like it. A mention (@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@movq I'm glad you like it. A mention (@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@movq I'm glad you like it. A mention (@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@mckinley Thanks for the feedback.
1. Yeah I agrees that nick sound not be part of syntax. Any valid URL to a twtxt.txt-file should be enough and is more clear, so it is not confused with a email (one of the the issues with webfinger and fedivese handles)
2. I think any valid URL would work, since we are not bound to look for exact matches. Accepting both http and https as well as a gemni and gophe could all work as long as the path to the twtxt.txt is the same.
3. My idea is that you quote the timestamp as it is in the original twtxt.txt that you are referring to, so you can do it by simply copy/pasting. Also what are the change that the same _human_ will make two different posts within the same second?!
Regarding the whole cryptographic keys for identity, to me it seems like an unnecessary layer of complexity. If you move to a new house or city you tell people that you moved - you can do the same in a twtxt.txt. Just post something like "I move to this new URL, please follow me there!" I did that with my feeds at least twice, and you guys still seem to read my posts:)
@mckinley Thanks for the feedback.
1. Yeah I agrees that nick sound not be part of syntax. Any valid URL to a twtxt.txt-file should be enough and is more clear, so it is not confused with a email (one of the the issues with webfinger and fedivese handles)
2. I think any valid URL would work, since we are not bound to look for exact matches. Accepting both http and https as well as a gemni and gophe could all work as long as the path to the twtxt.txt is the same.
3. My idea is that you quote the timestamp as it is in the original twtxt.txt that you are referring to, so you can do it by simply copy/pasting. Also what are the change that the same _human_ will make two different posts within the same second?!
Regarding the whole cryptographic keys for identity, to me it seems like an unnecessary layer of complexity. If you move to a new house or city you tell people that you moved - you can do the same in a twtxt.txt. Just post something like "I move to this new URL, please follow me there!" I did that with my feeds at least twice, and you guys still seem to read my posts:)
@mckinley Thanks for the feedback.
1. Yeah I agrees that nick sound not be part of syntax. Any valid URL to a twtxt.txt-file should be enough and is more clear, so it is not confused with a email (one of the the issues with webfinger and fedivese handles)
2. I think any valid URL would work, since we are not bound to look for exact matches. Accepting both http and https as well as a gemni and gophe could all work as long as the path to the twtxt.txt is the same.
3. My idea is that you quote the timestamp as it is in the original twtxt.txt that you are referring to, so you can do it by simply copy/pasting. Also what are the change that the same _human_ will make two different posts within the same second?!
Regarding the whole cryptographic keys for identity, to me it seems like an unnecessary layer of complexity. If you move to a new house or city you tell people that you moved - you can do the same in a twtxt.txt. Just post something like "I move to this new URL, please follow me there!" I did that with my feeds at least twice, and you guys still seem to read my posts:)
@mckinley Thanks for the feedback.
1. Yeah I agrees that nick sound not be part of syntax. Any valid URL to a twtxt.txt-file should be enough and is more clear, so it is not confused with a email (one of the the issues with webfinger and fedivese handles)
2. I think any valid URL would work, since we are not bound to look for exact matches. Accepting both http and https as well as a gemni and gophe could all work as long as the path to the twtxt.txt is the same.
3. My idea is that you quote the timestamp as it is in the original twtxt.txt that you are referring to, so you can do it by simply copy/pasting. Also what are the change that the same _human_ will make two different posts within the same second?!
Regarding the whole cryptographic keys for identity, to me it seems like an unnecessary layer of complexity. If you move to a new house or city you tell people that you moved - you can do the same in a twtxt.txt. Just post something like "I move to this new URL, please follow me there!" I did that with my feeds at least twice, and you guys still seem to read my posts:)
The tag URI scheme looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick?
Instead of using tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:
1. (reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)
2. (in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
3. (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
I know it's longer that 7-11 characters, but it's self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex: \\([\\w-]*reply[\\w-]*\\:
Is this something that would work?
The tag URI scheme looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick?
Instead of using tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:
1. Z)'
2. (in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)'
2. Z)'
I know it's longer that 7-11 characters, but it's self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex: \\([\\w-]*reply[\\w-]*\\:
Is this something that would work?
The tag URI scheme looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick?
Instead of using tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:
1. (reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)
2. (in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
3. (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
I know it's longer that 7-11 characters, but it's self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex: \([\w-]*reply[\w-]*\:
Is this something that would work?
The tag URI scheme looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick?
Instead of using tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:
1. (reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)
2. (in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
3. (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
I know it's longer that 7-11 characters, but it's self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex: \([\w-]*reply[\w-]*\:
Is this something that would work?
The tag URI scheme looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick?
Instead of using tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:
1. (reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)
2. (in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
3. (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
I know it's longer that 7-11 characters, but it's self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex: \([\w-]*reply[\w-]*\:
Is this something that would work?
The tag URI scheme looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick?
Instead of using tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:
1. (reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)
2. (in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
2. (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
I know it's longer that 7-11 characters, but it's self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex: \\([\\w-]*reply[\\w-]*\\: - Is this something that would work?
The tag URI scheme looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick?
Instead of using tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:
1. (reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)
2. (in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
3. (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
I know it's longer that 7-11 characters, but it's self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex: \([\w-]*reply[\w-]*\:
Is this something that would work?