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.tldFor 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.tldFor 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.tldFor 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.tldFor 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.tldFor 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.tldFor 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.tldFor 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.tldFor 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;)
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;)
application/activity+json in https://webfinger.net/lookup/?resource=sorenpeter@norrebro.space
{
"rel": "self",
"type": "application/activity+json",
"href": "https://norrebro.space/users/sorenpeter"
},
Then it would also make sense to define a Link Relations but should that then link to something like
https://twtxt.dev/webfinger.html where we can describe the spec?
application/activity+json in https://webfinger.net/lookup/?resource=sorenpeter@norrebro.space
{
"rel": "self",
"type": "application/activity+json",
"href": "https://norrebro.space/users/sorenpeter"
},
Then it would also make sense to define a Link Relations but should that then link to something like
https://twtxt.dev/webfinger.html where we can describe the spec?
application/activity+json in https://webfinger.net/lookup/?resource=sorenpeter@norrebro.space
{
"rel": "self",
"type": "application/activity+json",
"href": "https://norrebro.space/users/sorenpeter"
},
Then it would also make sense to define a Link Relations but should that then link to something like
https://twtxt.dev/webfinger.html where we can describe the spec?
application/activity+json in https://webfinger.net/lookup/?resource=sorenpeter@norrebro.space
{
"rel": "self",
"type": "application/activity+json",
"href": "https://norrebro.space/users/sorenpeter"
},
Then it would also make sense to define a Link Relations but should that then link to something like
https://twtxt.dev/webfinger.html where we can describe the spec?
And for people who don't like PHP you can always just go with Added WebFinger support to my email address using one rewrite rule and one static file. or simply putting a static JSON in place for
.well-know/webfinger
And for people who don't like PHP you can always just go with Added WebFinger support to my email address using one rewrite rule and one static file. or simply putting a static JSON in place for
.well-know/webfinger
And for people who don't like PHP you can always just go with Added WebFinger support to my email address using one rewrite rule and one static file. or simply putting a static JSON in place for
.well-know/webfinger
And for people who don't like PHP you can always just go with Added WebFinger support to my email address using one rewrite rule and one static file. or simply putting a static JSON in place for
.well-know/webfinger