Open ghost opened 8 years ago
I really think there should be a metadata block either at the top of twtxt.txt or in another file. You could expose things like preferred username (so you could allow custom nicks for each client and still have @-replies work), a list of people you're following, etc.
IMHO, there are two major aspects here -- discovery as in "who else is using this" (i.e. what other addresses can I "query"?) and discovery as in "network discovery/user identification", as Benaiah describes above.
The former could probably be done with a simple directory in the beginning, which can be propagated via a blockhain-ish thing if keeping an up-to-date list that's available to everyone is important. In order to not have it ruin everything @Benaiah mentioned (custom nicks for each clients and so on), metadata has to be kept (and served) by each user. By the way, if you look at it from just the right angle, this is what finger was doing, in a highly rudimentary manner.
Implementation-wise, I guess a set of utils that allow maintaining and sharing/syncing the directory among a group of people would be interesting, maybe? The metadata at the top of the file could contain a listing of the groups in whose directories the user is subscribed (i.e. thus acknowledging that (s)he is a part of that "network"), which would help in discovery, too.
I'm just throwing ideas here, I just read about this on HN and one thing led to another... I can try to put them in a more organized form if you'd like. Maybe after I set twtxt up myself, so that I don't speak from theory only, that's usually not a recipe for good things. Ew.
Having something like:
<meta name="twtxt" value="https://example.org">
in the website to state, that this profile has a twtxt file, would be good, too.
If you add something like #6 and sending a message with @example.org is automatically resolved with this meta tag, following new peoples by seeing them in tweets by other people should be easy.
See als #28 about mentions
throwing this out there: discover twtxt urls by email address using dns:
kitchen@kitchen.io -> kitchen._twtxt.kitchen.io TXT http://bucket.kitchen.io/twtxt.txt
I feel like there should be an extra layer between "kitchen" and "_twtxt.kitchen.io" though, but I'm not sure exactly what.
Then I could do something like: twtxt follow kitchen@kitchen.io
and it would Just Work™
@kitchen it's a pity NAPTR
records are so uncommon, or you could do, e.g.:
somebody.example.com. 3600 IN NAPTR 100 100 "u" "E2U+twtxt:Personal" "!^.*$!https://example.com/twtxt.txt!" .
corresponding to the twtxt
file for somebody@example.com
.
I feel like NAPTR is the semantically correct RR type here, but my stomach just can't take that record format :P
On Tue, Feb 9, 2016 at 12:43 PM, Klaus Alexander Seistrup < notifications@github.com> wrote:
@kitchen https://github.com/kitchen it's a pity NAPTR records are so uncommon, or you could do, e.g.:
somebody.example.com. 3600 IN NAPTR 100 100 "u" "E2U+twtxt:Personal" "!^.*$!https://example.com/twtxt.txt!" .
corresponding to the twtxt file for somebody@example.com.
— Reply to this email directly or view it on GitHub https://github.com/buckket/twtxt/issues/3#issuecomment-182054980.
@kitchen it's the semantically korrekt RR type, that's right, and the format is just awful. So perhaps we should just be thankful that not all DNS providers support this exotic RR type.
One way of increasing discoverability could be to include twtxt.txt
URL and @username
in the HTTP User-Agent
string, e.g.:
twtxt/1.2.3 (+https://example.com/twtxt.txt; @somebody)
This way at least people who have access to their webserver logs can see who are fetching their twtxt.txt
file.
@kseistrup This does not yet solve the whole problem, but I really like this idea!
If no one disagree with this - I'll implement it.
:+1: this way people could see in the logs who is following them ;)
Am Donnerstag, 11. Februar 2016 schrieb Timo Furrer :
@kseistrup https://github.com/kseistrup This does not yet solve the whole problem, but I really like this idea!
If no one disagree with this - I'll implement it.
— Reply to this email directly or view it on GitHub https://github.com/buckket/twtxt/issues/3#issuecomment-182744924.
But use something like @<username https://example.org> to match with the @mentions syntax.
Am Donnerstag, 11. Februar 2016 schrieb Jan Schütze :
:+1: this way people could see in the logs who is following them ;)
Am Donnerstag, 11. Februar 2016 schrieb Timo Furrer :
@kseistrup https://github.com/kseistrup This does not yet solve the whole problem, but I really like this idea!
If no one disagree with this - I'll implement it.
— Reply to this email directly or view it on GitHub https://github.com/buckket/twtxt/issues/3#issuecomment-182744924.
@DracoBlue I think if we implement it we should stick to the User Agent Format - Which is like @kseistrup proposed.
@timofurrer ok! good point!
@kseistrup Had the exact same idea of including twtxt nick and URL in the user-agent string. I’ll open a new issue for this one! :+1:
yeah, I like this idea - I will implement it for the twtxt directory agent
Can you start a user agent string with a URL like that? 😐
On Thursday, 11 February 2016, Christine Dodrill notifications@github.com wrote:
And added to twtxtlist https://git.xeserv.us/xena/twtxtlist/commit/69b3680361d3e5f1c61c7d84c672c348f7220800 as well.
— Reply to this email directly or view it on GitHub https://github.com/buckket/twtxt/issues/3#issuecomment-182810838.
@reednj doesn't seem like it:
The User-Agent request-header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. Although it is not required, user agents should include this field with requests. The field can contain multiple product tokens (Section 3.7) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens are listed in order of their significance for identifying the application.
Product tokens are used to allow communicating applications to identify themselves via a simple product token, with an optional slash and version designator. Most fields using product tokens also allow subproducts which form a significant part of the application to be listed, separated by whitespace. By convention, the products are listed in order of their significance for identifying the application.
Product tokens should be short and to the point -- use of them for advertizing or other non-essential information is explicitly forbidden. Although any token character may appear in a product- version, this token should only be used for a version identifier (i.e., successive versions of the same product should only differ in the product-version portion of the product value).
User-Agent = "User-Agent" ":" 1*( product | comment )
product = token ["/" product-version]
product-version = token
How about (ab)using the Referer
header instead?
Actually, the comment part of the User-Agent allows it:
Comments may be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part of the field value.
comment = "(" *( ctext | comment ) ")" ctext = <any TEXT excluding "(" and ")">
Edit: To be clear, starting a UA with a URI is not allowed, but you can place it in the comment part:
twtxt list/version (+https://twtxtlist.cf; +https://xena.greedo.xeserv.us/files/xena.txt; @xena)
Please let's discuss this at this ticket: https://github.com/buckket/twtxt/issues/63
Using DNS, and the NAPTR record in particular, to point to twtxt files seems like a really cool idea. :neckbeard: Maybe we can/should(?) include support for that even if not many will use that feature.
There is nothing that prevents a twt'er from announcing their stream in a NAPTR record, and I'm all for the idea (although my own DNS provider doesn't support that record type). But how will consumers discover the email address of said twtxt user (save for running their entire address books through a NAPTR lookup)? That said, I believe that the NAPTR and User-Agent methods are my best suggestions for discoverability. Perhaps a cup of coffee will help — I'll be back on this later.
NAPTR is cool idea, but as you say, the email address then would have to be discovered first. And very many people use email services that don't support this at all. (gmail anyone?)
But ok, since we're talking people who are self hosting a txtfile, perhaps a higher amount actually use "alternative" email providers, or even run their own...
@quite, good point!
A cup of :coffee: later I am thinking if /humans.txt
could be a place to put information about a twtxt stream. Another possibility is to put a <link/>
element in one's homepage, e.g.:
<link rel="alternate" type="text/plain; charset=utf-8" title="Here's my twtxt stream" href="https://example.com/twtxt.txt" hreflang="en"/>
Just a side note: as an experiment I put my twtxt URLs in the /humans.txt
file on my website and I decided to use the mention format:
TwTxt (English): @<kas https://enotty.dk/twtxt.txt>
TwTxt (dansk): @<kasdk https://enotty.dk/kasdk.txt>
Guess what: I just found out that Google is now looking for
https://enotty.dk/kasdk.txt%3E.
so that was not a success (I wonder where it got the final dot from, though). Now I have changed the lines in /humans.txt
to
TwTxt (English): @kas https://enotty.dk/twtxt.txt
TwTxt (dansk): @kasdk https://enotty.dk/kasdk.txt
Can we make all letters lower case?
@timofurrer, of couse. /humans.txt
is a free-form file meant for human consumption.
Yep. But it's not meant for bots, is it? http://humanstxt.org/
@DracoBlue correct.
I like the:
<link rel="alternate" type="text/plain; charset=utf-8" title="Here's my twtxt stream" href="https://example.com/twtxt.txt" hreflang="en"/>
version! Maybe a registered media type would make detection easier:
<link rel="alternate" type="text/twtxt; charset=utf-8" title="Here's my twtxt stream" href="https://example.com/twtxt.txt" hreflang="en"/>
PS: In this case one would have to register text/twtxt at http://www.iana.org/cgi-bin/mediatypes.pl
I don't mean to be rude but I for one strongly believe that twtxt isn't a social network like Facebook. I believe twtxt is meant to be for activists, hackers (mentioned in the project description). SO if we include this Recommendations or "People you may know" I think it would compromise the project.
No offense to anyone but that is what I truly felt.
A way to discover people you might want to follow would be cool.
Maybe by exposing a list of followers-of-followers?