@<url> form of mentions. **Strictly** require that all mentions include a nickname/name; i.e: @<name url>.
@<url> form of mentions. **Strictly** require that all mentions include a nickname/name; i.e: @<name url>.
Note, I manually added a nick to this reply.
@<url> then I have to do quick a bit of dancing to figure out how to render such mentions sanely π
π
@<url> then I have to do quick a bit of dancing to figure out how to render such mentions sanely π
π
-
yarnd @prologic (me and others)-
jenny @movq-
tt @lyse-
Timeline @darch / @eapl.me and others-
twtxt-el? -- @androsFull list of supported and widely used clients can be found at https://twtxt.dev/clients.html -- which I note a few above are _actually_ missing from this page haha π€£
-
yarnd @prologic (me and others)-
jenny @movq-
tt @lyse-
Timeline @darch / @eapl.me and others-
twtxt-el? -- @androsFull list of supported and widely used clients can be found at https://twtxt.dev/clients.html -- which I note a few above are _actually_ missing from this page haha π€£
> Mentions are embedded within the text in either
@<source.nick source.url> or @<source.url> format \nI'd just continue supporting it, even though I don't see it all that often in the wild. I guess more common is the case where just a nick is given, which is illegal. But yarnd users seem to produce it every now and then.
What's the motivation for deprecation?
> Mentions are embedded within the text in either
@<source.nick source.url> or @<source.url> format [β¦]I'd just continue supporting it, even though I don't see it all that often in the wild. I guess more common is the case where just a nick is given, which is illegal. But yarnd users seem to produce it every now and then.
What's the motivation for deprecation?
tt currently supports all three forms: @<nick url>, @<url> and even the illegal @<nick>. The difference between the last two is whether the token in angle brackets looks like a URL or not. Whenever a nick is available, the nick is rendered. In case there is just a URL, it tries to resolve the nick from the subscriptions. If that also does not work, it displays the URL.
> Whatβs the motivation for deprecation?
Namely that without the mention having a label (_as such_) it becomes very hard to render it in any sane/nice way. I think we should just stick to
@<label url> personally. It makes implementations have to worry about far less edge cases.
> Whatβs the motivation for deprecation?
Namely that without the mention having a label (_as such_) it becomes very hard to render it in any sane/nice way. I think we should just stick to
@<label url> personally. It makes implementations have to worry about far less edge cases.
> Was there ever a reason to do that? π€
I'm not sure to be honest. I have no idea why you'd ever want to do a "nameless" @-mention.
As an aside, if we could all agree, I'd personally just say we scrap this whole fragile broken shit and bring out WebMentions and be done with it. And then mentions are always
@nick@domain and looked up, cached and can never be screwed up haha π€£
> Was there ever a reason to do that? π€
I'm not sure to be honest. I have no idea why you'd ever want to do a "nameless" @-mention.
As an aside, if we could all agree, I'd personally just say we scrap this whole fragile broken shit and bring out WebMentions and be done with it. And then mentions are always
@nick@domain and looked up, cached and can never be screwed up haha π€£
@nick@domain thing that yarnd invented) and be done. It's really that simple.When yarnds peer with each other, the odds of actually having come across that feed URL in the past are higher than with traditional clients that only have their local set of subscribed feeds. One additional improvment would be to also look at all the mentions and see if somebody used a nick for that URL and go with that.
Yeah, yarnd currently renders some really weird shit when the mention contains just a URL, but I'd call that a bug for sure.
Personally, I do not like the
@nick@domain syntax at all. It looks silly to my eyes. What might have also contributed is the fact of this mentions syntax gotten screwed up so many times by yarnd in the past. But that's a totally different topic.
prosoalIs it a typo of Proposal right? =P (Genuinely asking)
prosoalIs it a typo of Proposal right? =P (Genuinely asking)
- 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
@nick@domain support by doing a webfinger lookup to get the URL.