Decentral Solution for @mentions or search

[DracoBlue]

Since everyone has his/her own twtxt.txt, we cannot support @mention like on twitter locally. Except if we follow those people already.

If we say that we have registries - custom hosted aggregators like http://twtxt.reednj.com/ - they could provide an api to get all mentions for a twtxt uri (e.g. http://example.org/twtxt.txt like suggested in #6, if a twtxt tweet looks like this: TIMESTAMP @<http://example.org/twtxt.txt> how are you

Api Response could look like this:

TIMESTAMP https://dracoblue.net/twtxt @<http://example.org/twtxt.txt> how are you

if I messaged example.org with a mention.

The advantage of this approach is, that every client can decide at which registry he is registered and which he wants to query for possible mentions. Like a federated web search ;).

UPDATE 2

An api-doc with swagger UI can be found here https://registry.twtxt.org/swagger-ui/ and a PR is made here #74

UPDATE

Implemented a server for this at https://github.com/DracoBlue/twtxt-registry - will work on a PR now.

A demo runs on https://registry.twtxt.org/api/plain/mentions?url=https://buckket.org/twtxt.txt and gives:

@<dracoblue https://dracoblue.net/twtxt.txt>    2016-02-09T12:57:59.000Z    @<buckket https://buckket.org/twtxt.txt> something like https://gitter.im/ or a freenode channel?
@<dracoblue https://dracoblue.net/twtxt.txt>    2016-02-08T22:51:47.000Z    @<buckket https://buckket.org/twtxt.txt> looks nice ;)

[Benaiah]

I think handling mentions as meta data would work better, and allow for full decentralization. For example, if I had “bob” with the url “http://example.com/bob.txt”, and I posted something that included “@bob”, there could be a metadata entry associating @bob with the url, allowing bob to determine it was indeed him. This would allow mentions without a central registry, which seems to defeat some of the advantages of the decentralized protocol.

[timofurrer]

@Benaiah I think the register @DracoBlue mentioned was supposed to be the solution if bob is not following you - he'll never see that he was mentioned..

[kitchen]

I like the idea of user nicknames being local aliases for folks rather than authoritative things. I believe even internally at $micro_blogging_service they use unique account identifiers when storing mention data, so if you mention someone and they change their username, the mention updates to reflect that.

I also like the idea of registries acting as mention brokers. Maybe there could even be some metadata along with the twtxt.txt file that says your preferred username, preferred registry(ies), mention gateways, etc.

I don't know if that should live in twtxt.txt proper, or if that should be a twtxt.user.txt or something, though.

[timofurrer]

I totally agree with the aliases approach. It makes your user unique - because of the URI to the twtxt file. Mentions should be expanded to the URI of the user who's being mentioned. To mention someone you can either use your local alias for the mentioned user or, and if no alias is available, the preferred alias of this user is taken.

I like it better to have the configurations in a separate file instead of twtxt.txt itself. I would try to keep the twtxt.txt as simple as possible - and put only tweets (and in future maybe their metadata) there.

[kitchen]

having the metadata separate also means you can check for them independently. if I change my ... say... profile pic, it goes into the metadata file and you don't need to re-download my entire txtxt.txt file

[Benaiah]

See also issue #6. I like the @ syntax suggested there, with client-side transformation of that to and from a human-readable @USERNAME representation.

[tedder]

The nickname issue seems to be orthogonal to the "decentralized mentions" issue. The issue is sending mentions to someone who doesn't follow me (yet). Using a few centralized message-passers in this case seems useful; they could be baked into the default configuration, which allows them to be removed if desired.

[Benaiah]

A webhook system, where the sender sends a request to a url to notify the person being mentioned, could also work. This could be combined with the registry system, so you could have a third party handle your notifications if you prefer. There are a couple advantages and drawbacks:

• It would require a second url in order to handle notifications. This could be either in a metadata section in the twtxt.txt or manually specified when you add someone. This is already required by the registry idea.
• It would require the sender to either be online when they send a message or have a system to send the webhook requests when they get online.
• It would allow non-follower notifications without a third party. This, to me, is the most significant advantage.

Apologies for initially missing the point of the issue.

[tedder]

I love the idea of a webhook. OTOH, it increases complexity/"overhead" by requiring not only a server but an always-on server. Perhaps we also allow a broker who can store mentions; making this the default would keep this project from being too difficult to set up for new users.

[tedder]

further musing- a webhook allows for DMs/private messages.

[Benaiah]

@tedder: a "broker who can store mentions" is exactly what I meant when I said "this could be combined with the registry system" - a third party could watch for your mentions for you, and notify you through other means - whether it be IFTT's Do app, forwarding to another social service, or some other way of notifying you.

My main concern is that I do not want people who eschew any third party to be left out of important parts of the protocol. The decentralized yet easy-to-deploy nature of twtxt is its biggest strength, so I'd hate to see an addition to the protocol that hampers those goals. It seems to me that allowing for a brokered notifications system without requiring it is a better scheme than requiring a broker for the sake of a simpler server.

[mmk2410]

Another idea would be to send a email to the person that has been mentioned.

So if you mention someone, twtxt could fetch the meta information about this person, get an email address and sent a mail. Something like this: https://gist.github.com/mmk2410/837686d63385b63d1d8b

[Benaiah]

@mmk2410: sending email seems like a bit of a big task for somebody who's just trying to host a lightweight twitter system. If you really need email notifications, that could be handled by the webhook server, whether that be one you run yourself or a broker that does it for you.

[DracoBlue]

Yep. A broker or registry should do this. Twtxt Hosting should stay as simple like hosting a textfile in 1991 ;).

Am Mittwoch, 10. Februar 2016 schrieb Benaiah Mischenko :

@mmk2410 https://github.com/mmk2410: sending email seems like a bit of a big task for somebody who's just trying to host a lightweight twitter system. If you really need email notifications, that could be handled by the webhook server, whether that be one you run yourself or a broker that does it for you.

— Reply to this email directly or view it on GitHub https://github.com/buckket/twtxt/issues/28#issuecomment-182166287.

http://dracoblue.net

[DracoBlue]

Implemented a server for this at https://github.com/DracoBlue/twtxt-registry - will work on a PR now.

A demo runs on https://registry.twtxt.org/api/plain/mentions?url=https://buckket.org/twtxt.txt and gives:

@<dracoblue https://dracoblue.net/twtxt.txt>    2016-02-09T12:57:59.000Z    @<buckket https://buckket.org/twtxt.txt> something like https://gitter.im/ or a freenode channel?
@<dracoblue https://dracoblue.net/twtxt.txt>    2016-02-08T22:51:47.000Z    @<buckket https://buckket.org/twtxt.txt> looks nice ;)

[buckket]

@DracoBlue Like the idea, as well as the proposed format. We should mention it in the docs so that everyone is using the same format. This would then allow us to implement support for retrieving mentions in the client, while allowing the user to decide if or which registry he want’s to use.

[DracoBlue]

Yep. Can somebody help with adding it to the docs?

The client should have in my opinion a set of registries to listen to in configuration.

Btw. we would need the own destination for the twtxt.txt file sonewhere in the config though.

[buckket]

@DracoBlue There already is twtfile and twturl in the config, so what do you mean?

[DracoBlue]

Ah perfect!

Am Samstag, 13. Februar 2016 schrieb buckket :

@DracoBlue https://github.com/DracoBlue There already is twtfile and twturl in the config, so what do you mean?

— Reply to this email directly or view it on GitHub https://github.com/buckket/twtxt/issues/28#issuecomment-183667239.

http://dracoblue.net

[DracoBlue]

Added with #74 the documentation. Can somebody with more advanced python knowledge incorporate this into the client? Maybe as twtxt mentions ?

[timofurrer]

I can have a look at it!

[DracoBlue]

:+1:

[Benaiah]

@DracoBlue how is the registry implemented? Is it scanning a bunch of twtxt users and checking for mentions? I still think the webhook system would have significant advantages, as it would allow for both third-party and first-party notifications of mentions.

[DracoBlue]

@Benaiah it has its own database (I use elasticsearch) where it stores tweets and users. It frequently queries the twtxt.txt of those and uses a memcache to get 304 Not Modified.

If somebody queries for mentions, it will use the providef twtxt.txt url and lookup all tweets in elasticsearch, which mention this url.

Of course one could implement it with different technologies.

But: webhooks would be also awesome, because this could trigger the fetch in the api instantly. So the registry could e.g. push to connected clients (e.g. HTML5 Notifications or Pushmessages for iOS/Android).

[ghost]

Instead since we are mentioning a user whom we are following why don't we include the user (bob in this example)'s twtxt file via our list of following users (I'm thinking a brute force search in our users following file would land if into the user whom we've tagged) and then we can create a parse_mentions.py file which will do a preprocessing of this by linking all mentions of @bob with his HTTP twtxt file link (terminals have hyperlink click support by default).

Also if there are multiple bob's on click enter after typing a tweet, a prompt would be shown to select the appropriate bob. simple right :/