auto syntax exists (to allow specifying a return type that depends on the argument).
nick is identical to a level of a domain; in order to show shorter format nicks within clients, i.e: @nick.domain.ltd or @nick.ltd instead of a @nick@nick.domain.ltd or @nick@nick.ltd. Just like what @sorenpeter already did with the nick = domain case. _(unless I'm missing the point)_
nick is identical to a level of a domain; in order to show shorter format nicks within clients, i.e: @nick.domain.ltd or @nick.ltd instead of a @nick@nick.domain.ltd or @nick@nick.ltd. Just like what @sorenpeter already did with the nick = domain case. _(unless I'm missing the point)_
nick is identical to a level of a domain; in order to show shorter format nicks within clients, i.e: @nick.domain.ltd or @nick.ltd instead of a @nick@nick.domain.ltd or @nick@nick.ltd. Just like what @sorenpeter already did with the nick = domain case. _(unless I'm missing the point)_
https://youtu.be/FhMOAydy7EY
(Sim, mais Marilyn Manson: The Last Day On Earth)
https://youtu.be/FhMOAydy7EY
(Sim, mais Marilyn Manson: The Last Day On Earth)
- nick = subdomain: https://aelaraji.com/timeline/profile?url=https://lyse.isobeef.org/twtxt.txt ->
lyse.isobeef.org- nick = second level domain: https://aelaraji.com/timeline/profile?url=https://aelaraji.com/twtxt.txt ->
aelaraji.com
- nick = subdomain: https://aelaraji.com/timeline/profile?url=https://lyse.isobeef.org/twtxt.txt ->
lyse.isobeef.org- nick = second level domain: https://aelaraji.com/timeline/profile?url=https://aelaraji.com/twtxt.txt ->
aelaraji.com
- nick = subdomain: https://aelaraji.com/timeline/profile?url=https://lyse.isobeef.org/twtxt.txt ->
lyse.isobeef.org- nick = second level domain: https://aelaraji.com/timeline/profile?url=https://aelaraji.com/twtxt.txt ->
aelaraji.com
~ is so commonly used as a <username> that we should just suppose that out of the box by all clients for display purposes.
~ is so commonly used as a <username> that we should just suppose that out of the box by all clients for display purposes.
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