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.
@nick@domain.tls
I think Webfinger is the way to go. It has enough information to know where to find that nick's URL.@prologic does that webfinger fork made by darch work OK with yarn as it is now? (I've never used it, so I'm researching about it)
https://darch.dk/.well-known/webfinger/
Wife and I agreed on hibernate until January, just visiting relatives but avoiding any kind of shopping. I tried buying something like 2 or 3 days ago and it's insane :o
Good luck! :)
My first thought was creating a subdomain with the name of the podcast
mordiscos.eapl.me
Then I watched that the software allows many podcasts in the same domain, so I had to pick a handle:
https://mordiscos.eapl.me/@podcast
So now I have
@podcast@mordiscos.eapl.me
when this one is 'more correct' @mordiscos@podcast.eapl.me
or it could even be @mordiscos.eapl.me
I wasn't aware of all that when I setup Castopod (documentation might improve a lot, IMO)
My point here is that it's something important to think from the start, otherwise is painful to change if it's already being used like that.
I agree on displaying a short
@nick
.We could hover on the nick to see the full detail which could be
@nick@domain.tls
or the full URLAlso it could be a display option in Preferences in case your account starts showing many collisions.
The disambiguation for collisions is the .txt URL and the nick inside it, right ?
needed to get out and get away from everything for a bit. turned into eight miles but was just what i needed.
#running
needed to get out and get away from everything for a bit. turned into eight miles but was just what i needed.
#running
needed to get out and get away from everything for a bit. turned into eight miles but was just what i needed.
#running
nick@domain
is preferred over just @nick
in the first place. The twtxt world here is so small (and hopefully will always be) that duplicate nicks are just not an issue from my point of view. And even if there are several feeds with the same nicks, one probably does not follow both of them. Yes, there's the birthday paradox, but I'd guess we have a slightly larger nickname space than days in a year.
If NICK = DOMAIN then only show @DOMAIN
So 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 @DOMAIN
So 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 @DOMAIN
So 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 @DOMAIN
So 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 @DOMAIN
So 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 @DOMAIN
So 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 @DOMAIN
So 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 @DOMAIN
So 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;)
- https://adventofcode.com/2021/day/24
- https://adventofcode.com/2024/day/24
And maybe even:
- https://adventofcode.com/2023/day/25
- https://adventofcode.com/2024/day/14
The first two can be solved by creativity and exploration, they’re not just “use algorithm
$foo
” like many other puzzles. They require hardly any programming at all.The other two do need a bit of programming, but 2024/14 was pretty interesting and unconventional.
- https://adventofcode.com/2021/day/24
- https://adventofcode.com/2024/day/24
And maybe even:
- https://adventofcode.com/2023/day/25
- https://adventofcode.com/2024/day/14
The first two can be solved by creativity and exploration, they’re not just “use algorithm
$foo
” like many other puzzles. They require hardly any programming at all.The other two do need a bit of programming, but 2024/14 was pretty interesting and unconventional.
- https://adventofcode.com/2021/day/24
- https://adventofcode.com/2024/day/24
And maybe even:
- https://adventofcode.com/2023/day/25
- https://adventofcode.com/2024/day/14
The first two can be solved by creativity and exploration, they’re not just “use algorithm
$foo
” like many other puzzles. They require hardly any programming at all.The other two do need a bit of programming, but 2024/14 was pretty interesting and unconventional.
- https://adventofcode.com/2021/day/24
- https://adventofcode.com/2024/day/24
And maybe even:
- https://adventofcode.com/2023/day/25
- https://adventofcode.com/2024/day/14
The first two can be solved by creativity and exploration, they’re not just “use algorithm
$foo
” like many other puzzles. They require hardly any programming at all.The other two do need a bit of programming, but 2024/14 was pretty interesting and unconventional.
> Ahh this is too easy. Give me a human.
🤣 #AI #Sucks
> Ahh this is too easy. Give me a human.
🤣 #AI #Sucks