Resolve Nicknames, which are Domains

[DracoBlue]

I host a twtxt file at https://dracoblue.net/twtxt.txt

If I reply to somebody like @buckket it's not clea if other people saved him as @buckket, too. Or a different person.

Would it be possible to have something like @example.org resolves preferably to the person who hosts https://example.org/twtxt.txt?

[buckket]

I'm currently thinking about the possibilities. One solution might be adding transparent metadata by convention, i.e. clients which know about them will filter and process them, whilst others just show the plain text without touching anything. This would then allow such behaviour.

But I don’t really want to introduce more complexity than really necessary, though having a bit more comfort would definitely be a plus.

I'm open for suggestions.

[DracoBlue]

Yep! Convention helps in this case to keep it simple and like you say: clients, who don't know abour this, render this as plaintext.

Having meta data in the text like:

@example how are you

is stored in twtxt.txt like this:

TIMESTAMP     @https://example.org/twtxt.txt how are yoz

and clients map this to @example if they follow this feed, too.

[welandtb]

What if more people want to host their twtxt on the same website though? E.g. several people working on a common project or in an organization. IMHO, the "nickname" should map to the full URI of the file, not to the domain name.

I.e. if Alice hosts her twtxt at https://example.org/twtxt_alice.txt and Bob hosts his at https://example.org/twtxt_bob.txt (maybe they're both working on ExampleOS, an open source operating system), clients should be able to map @alice to https://example.org/twtxt_alice.txt, not just to example.org .

Leaving URI <-> Nick mapping to clients does sound sane to me though. It's much as it happens IRL, where people who know Alice associate her identifying data with that particular Alice who they know, whereas for everyone else (who doesn't even know her name), she's "that girl waiting for the bus", "that girl who just said something about iPhones" and so on.

[buckket]

Okay, I propose the following:

Consider I’m following "bob" like this:
bob = http://example.org/twtxt.txt

Using twtxt tweet "@bob Hello Bob" will result in:
TIMESTAMP @<http://example.org/twtxt.txt> Hello Bob

Parsing my own status update will then again result in:
@bob Hello Bob

If you’re not following the URL it will look like this for you:
@<http://example.org/twtxt.txt> Hello Bob

Resolving a URL is completely client-sided. If an URL can’t be resolved let it be. This format is machine- as well as human-readable and won’t break anything.

Maybe we could/should replicate Twitter’s behaviour and hide such unresolved updates, because you apparently don’t know or don’t want to follow the recipient. On the other hand it would be a great way to get to know more users. A flag seems most appropriate.

Oh, and as @welandtb pointed out: the complete URL has to be used.

[DracoBlue]

@welandtb good point!

TIMESTAMP @<http://example.org/twtxt.txt> Hello Bob

looks good to me!

[dontdieych]

twt uri as identity?

resonable and easy to understand

[mkody]

@buckket @welandtb Looks good for me!
And what's interesting is that we could choose the name to display instead. You could add http://example.org/twtxt.txt has "bob", but I could use "bobby" instead if I want.

@dontdieych What do you mean, a twt uri?

[DracoBlue]

This: http://example.org/twtxt.txt is the uri.

Am Sonntag, 7. Februar 2016 schrieb Kody :

@buckket https://github.com/buckket @welandtb
https://github.com/welandtb Looks good for me!
And what's interesting is that we could choose the name to display
instead. You could add http://example.org/twtxt.txt has "bob", but I
could use "bobby" instead if I want.

@dontdieych https://github.com/dontdieych What do you mean, a twt uri?

—
Reply to this email directly or view it on GitHub
#6 (comment).

http://dracoblue.net

[buckket]

Okay, I’ve merged and updated #23. ✌️

But I’m not 100% happy about it right now, that’s why the changes currently reside in the mentions-branch. Go and check it out: 3fb1e7e

My problem is that styling tweets means including ANSI escape codes, but when later shortening the tweet to stay within 140 characters those will be counted as well, which leads to the problem that the visible length is smaller than it should be. Right now I’m calculating the length of the escape codes by unstyling the tweet again and subtracting the length of the styled from the unstyled tweet, which is then added to the 140 character limit.

tl;dr: We have to think about when and where we calculate the length of a tweet to shorten it appropriately. (Or should we even drop this feature?)

Edit: There is still some debugging to be done.

[DracoBlue]

The calculation sounds ok to me. The shortening should in my opinion be done on client side, while rendering. Imagine my URI is http://example.org/1122222445566534555433345555334555434555334555/twtxt.txt - then nobody could mention my user ;).

I think it's ok to apply the limit to what the user types (so "@DracoBlue how are you".length) and when rendering the tweets to what the user sees (like you already did).

[DracoBlue]

Or apply the length only to everything except the mention/color codes

[DracoBlue]

@buckket added some documentation for that feature at #42