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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
(#<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?
(#<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?
(#<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?
(#<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?
@<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 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 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 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 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 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 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>) ?!
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:)
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:)
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:)
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:)
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?
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?
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?
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?
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?
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?
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?
If we omit the protocol prefix from the way we do things now will that not solve most of the problems? In the case of
gemini://gemini.ctrl-c.club/~nristen/twtxt.txt they also have a working twtxt.txt at https://ctrl-c.club/~nristen/twtxt.txt ... damn I just notice the gemini. subdomain.Okay what about defining a prefers protocol as part of the hash schema? so 1: https , 2: http 3: gemini 4: gopher ?
If we omit the protocol prefix from the way we do things now will that not solve most of the problems? In the case of
gemini://gemini.ctrl-c.club/~nristen/twtxt.txt they also have a working twtxt.txt at https://ctrl-c.club/~nristen/twtxt.txt ... damn I just notice the gemini. subdomain.Okay what about defining a prefers protocol as part of the hash schema? so 1: https , 2: http 3: gemini 4: gopher ?
If we omit the protocol prefix from the way we do things now will that not solve most of the problems? In the case of
gemini://gemini.ctrl-c.club/~nristen/twtxt.txt they also have a working twtxt.txt at https://ctrl-c.club/~nristen/twtxt.txt ... damn I just notice the gemini. subdomain.Okay what about defining a prefers protocol as part of the hash schema? so 1: https , 2: http 3: gemini 4: gopher ?
If we omit the protocol prefix from the way we do things now will that not solve most of the problems? In the case of
gemini://gemini.ctrl-c.club/~nristen/twtxt.txt they also have a working twtxt.txt at https://ctrl-c.club/~nristen/twtxt.txt ... damn I just notice the gemini. subdomain.Okay what about defining a prefers protocol as part of the hash schema? so 1: https , 2: http 3: gemini 4: gopher ?
gemini://, https:// and only http:// (like in my own twtxt.txt) or construct something like like a webfinger id nick@domain (also used by mastodon etc.) from the domain and nick if there, else use domain as nick as well
gemini://, https:// and only http:// (like in my own twtxt.txt) or construct something like like a webfinger id nick@domain (also used by mastodon etc.) from the domain and nick if there, else use domain as nick as well
gemini://, https:// and only http:// (like in my own twtxt.txt) or construct something like like a webfinger id nick@domain (also used by mastodon etc.) from the domain and nick if there, else use domain as nick as well
gemini://, https:// and only http:// (like in my own twtxt.txt) or construct something like like a webfinger id nick@domain (also used by mastodon etc.) from the domain and nick if there, else use domain as nick as well
Or send them an email, so it would be an idea to add a
# contact = mailto:me@domain.net to ones twtxt.txt
Or send them an email, so it would be an idea to add a
# contact = mailto:me@domain.net to ones twtxt.txt
Or send them an email, so it would be an idea to add a
# contact = mailto:me@domain.net to ones twtxt.txt
Or send them an email, so it would be an idea to add a
# contact = mailto:me@domain.net to ones twtxt.txt