https://) and my markdown parser does not know how to handle but I see yarnd does it just fine.
https://) and my markdown parser does not know how to handle but I see yarnd does it just fine.
https://) and my markdown parser does not know how to handle but I see yarnd does it just fine.
https://) and my markdown parser does not know how to handle but I see yarnd does it just fine.
it look like your markdown image tags are missing the protocol part (
https://) so they don't render at least on my server: https://darch.dk/timeline/conv/3vtnszq
it look like your markdown image tags are missing the protocol part (
https://) so they don't render at least on my server: https://darch.dk/timeline/conv/3vtnszq
it look like your markdown image tags are missing the protocol part (
https://) so they don't render at least on my server: https://darch.dk/timeline/conv/3vtnszq
it look like your markdown image tags are missing the protocol part (
https://) so they don't render at least on my server: https://darch.dk/timeline/conv/3vtnszq
Right now you need to copy the markdown code yourself, but next up would be to lean some JS or use HTMX to make the process more smooth.
Right now you need to copy the markdown code yourself, but next up would be to lean some JS or use HTMX to make the process more smooth.
Right now you need to copy the markdown code yourself, but next up would be to lean some JS or use HTMX to make the process more smooth.
Right now you need to copy the markdown code yourself, but next up would be to lean some JS or use HTMX to make the process more smooth.
I like the minimal feel of sourcehut but it seem you have to pay if you want your, not just submit patches to others repos. But they also got IRC bouncer and mailing-lists included. Codeberg also looks appealing being based in Germany.
I like the minimal feel of sourcehut but it seem you have to pay if you want your, not just submit patches to others repos. But they also got IRC bouncer and mailing-lists included. Codeberg also looks appealing being based in Germany.
I like the minimal feel of sourcehut but it seem you have to pay if you want your, not just submit patches to others repos. But they also got IRC bouncer and mailing-lists included. Codeberg also looks appealing being based in Germany.
I like the minimal feel of sourcehut but it seem you have to pay if you want your, not just submit patches to others repos. But they also got IRC bouncer and mailing-lists included. Codeberg also looks appealing being based in Germany.
I also see you are using the Yellow CMS for your website🍋
I also see you are using the Yellow CMS for your website🍋
I also see you are using the Yellow CMS for your website🍋
I also see you are using the Yellow CMS for your website🍋
- For
@<nick url> we already got support- For
@<nick> the posting client should expand it to @<nick url>, if not then the reading client should just render it as @nick with no link.- For
@<url> the sending client should try to expand it to @<nick url>, if not then the reading client should try to find or construct a nick base on:1. Look in twtxt.txt for a
nick = 2. Use (sub)domain from URL
3. Use folder or file name from URL
- For
@<nick url> we already got support- For
@<nick> the posting client should expand it to @<nick url>, if not then the reading client should just render it as @nick with no link.- For
@<url> the sending client should try to expand it to @<nick url>, if not then the reading client should try to find or construct a nick base on:1. Look in twtxt.txt for a
nick = 2. Use (sub)domain from URL
3. Use folder or file name from URL
- For
@<nick url> we already got support- For
@<nick> the posting client should expand it to @<nick url>, if not then the reading client should just render it as @nick with no link.- For
@<url> the sending client should try to expand it to @<nick url>, if not then the reading client should try to find or construct a nick base on:1. Look in twtxt.txt for a
nick = 2. Use (sub)domain from URL
3. Use folder or file name from URL
- For
@<nick url> we already got support- For
@<nick> the posting client should expand it to @<nick url>, if not then the reading client should just render it as @nick with no link.- For
@<url> the sending client should try to expand it to @<nick url>, if not then the reading client should try to find or construct a nick base on:1. Look in twtxt.txt for a
nick = 2. Use (sub)domain from URL
3. Use folder or file name from URL
See it live at:
- nick = domain: https://darch.dk/timeline/profile?url=https://eapl.me/tw.txt
- nick ≠domain: https://darch.dk/timeline/profile?url=https://twtxt.net/user/prologic/twtxt.txt
- no nick, use domain: https://darch.dk/timeline/profile?url=https://akkartik.name/twtxt.txt
I'm not sure I like the leading
@ thou...
See it live at:
- nick = domain: https://darch.dk/timeline/profile?url=https://eapl.me/tw.txt
- nick ≠domain: https://darch.dk/timeline/profile?url=https://twtxt.net/user/prologic/twtxt.txt
- no nick, use domain: https://darch.dk/timeline/profile?url=https://akkartik.name/twtxt.txt
I'm not sure I like the leading
@ thou...
See it live at:
- nick = domain: https://darch.dk/timeline/profile?url=https://eapl.me/tw.txt
- nick ≠domain: https://darch.dk/timeline/profile?url=https://twtxt.net/user/prologic/twtxt.txt
- no nick, use domain: https://darch.dk/timeline/profile?url=https://akkartik.name/twtxt.txt
I'm not sure I like the leading
@ thou...
See it live at:
- nick = domain: https://darch.dk/timeline/profile?url=https://eapl.me/tw.txt
- nick ≠domain: https://darch.dk/timeline/profile?url=https://twtxt.net/user/prologic/twtxt.txt
- no nick, use domain: https://darch.dk/timeline/profile?url=https://akkartik.name/twtxt.txt
I'm not sure I like the leading
@ thou...
nick = _compared to just not defining a nick and let the client use the domain as the handle?What is not intuitive is that you put something in the nick field that is not to be taken literary. The special meaning of
_ is only clean if you read the documentation, compared to having something in nick that makes sense in the current context of the twtxt.txt.
nick = _compared to just not defining a nick and let the client use the domain as the handle?What is not intuitive is that you put something in the nick field that is not to be taken literary. The special meaning of
_ is only clean if you read the documentation, compared to having something in nick that makes sense in the current context of the twtxt.txt.
nick = _compared to just not defining a nick and let the client use the domain as the handle?What is not intuitive is that you put something in the nick field that is not to be taken literary. The special meaning of
_ is only clean if you read the documentation, compared to having something in nick that makes sense in the current context of the twtxt.txt.
nick = _compared to just not defining a nick and let the client use the domain as the handle?What is not intuitive is that you put something in the nick field that is not to be taken literary. The special meaning of
_ is only clean if you read the documentation, compared to having something in nick that makes sense in the current context of the twtxt.txt.
nick = _@domain.tld in the twtxt.txt?It seems more intuitive and userfriendly to just use:
nick = domain.tld and have then convention for clients to render the handle as **@domain.tld** instead of **@domain.tld@domain.tld**For a feed with no nick defined (eg. https://akkartik.name/twtxt.txt) it will also be simpler and make more sense to just use the domain as the nick and render it as **@domain.tld**
nick = _@domain.tld in the twtxt.txt?It seems more intuitive and userfriendly to just use:
nick = domain.tld and have then convention for clients to render the handle as **@domain.tld** instead of **@domain.tld@domain.tld**For a feed with no nick defined (eg. https://akkartik.name/twtxt.txt) it will also be simpler and make more sense to just use the domain as the nick and render it as **@domain.tld**
nick = _@domain.tld in the twtxt.txt?It seems more intuitive and userfriendly to just use:
nick = domain.tld and have then convention for clients to render the handle as **@domain.tld** instead of **@domain.tld@domain.tld**For a feed with no nick defined (eg. https://akkartik.name/twtxt.txt) it will also be simpler and make more sense to just use the domain as the nick and render it as **@domain.tld**
nick = _@domain.tld in the twtxt.txt?It seems more intuitive and userfriendly to just use:
nick = domain.tld and have then convention for clients to render the handle as **@domain.tld** instead of **@domain.tld@domain.tld**For a feed with no nick defined (eg. https://akkartik.name/twtxt.txt) it will also be simpler and make more sense to just use the domain as the nick and render it as **@domain.tld**
In yarnd I recall there is a setting for changing the heading of posts, but not for the two others as of yet.
I like the hover option for inline mentions. For the other places some like how yarnd does it in two line or " **nick** _(domain.tld)_ " could also work.
In yarnd I recall there is a setting for changing the heading of posts, but not for the two others as of yet.
I like the hover option for inline mentions. For the other places some like how yarnd does it in two line or " **nick** _(domain.tld)_ " could also work.
In yarnd I recall there is a setting for changing the heading of posts, but not for the two others as of yet.
I like the hover option for inline mentions. For the other places some like how yarnd does it in two line or " **nick** _(domain.tld)_ " could also work.
In yarnd I recall there is a setting for changing the heading of posts, but not for the two others as of yet.
I like the hover option for inline mentions. For the other places some like how yarnd does it in two line or " **nick** _(domain.tld)_ " could also work.
If NICK = DOMAIN then only show @DOMAINSo instead of **@eapl.me@eapl.me** it will just be **@eapl.me**
And it event seem that it will not break webfinger lookup: https://webfinger.net/lookup/?resource=%40darch.dk (at least not for how I've implemented webfinger on my sever for a single user;)
If NICK = DOMAIN then only show @DOMAINSo instead of **@eapl.me@eapl.me** it will just be **@eapl.me**
And it event seem that it will not break webfinger lookup: https://webfinger.net/lookup/?resource=%40darch.dk (at least not for how I've implemented webfinger on my sever for a single user;)
If NICK = DOMAIN then only show @DOMAINSo instead of **@eapl.me@eapl.me** it will just be **@eapl.me**
And it event seem that it will not break webfinger lookup: https://webfinger.net/lookup/?resource=%40darch.dk (at least not for how I've implemented webfinger on my sever for a single user;)
If NICK = DOMAIN then only show @DOMAINSo instead of **@eapl.me@eapl.me** it will just be **@eapl.me**
And it event seem that it will not break webfinger lookup: https://webfinger.net/lookup/?resource=%40darch.dk (at least not for how I've implemented webfinger on my sever for a single user;)