Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decentral Solution for @mentions or search #28

Open
DracoBlue opened this issue Feb 7, 2016 · 25 comments
Open

Decentral Solution for @mentions or search #28

DracoBlue opened this issue Feb 7, 2016 · 25 comments

Comments

@DracoBlue
Copy link
Contributor

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 ;)
@DracoBlue DracoBlue mentioned this issue Feb 7, 2016
@Benaiah
Copy link

Benaiah commented Feb 7, 2016

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
Copy link
Contributor

@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
Copy link
Contributor

kitchen commented Feb 7, 2016

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
Copy link
Contributor

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
Copy link
Contributor

kitchen commented Feb 7, 2016

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
Copy link

Benaiah commented Feb 7, 2016

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
Copy link
Contributor

tedder commented Feb 7, 2016

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
Copy link

Benaiah commented Feb 7, 2016

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
Copy link
Contributor

tedder commented Feb 7, 2016

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
Copy link
Contributor

tedder commented Feb 7, 2016

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

@Benaiah
Copy link

Benaiah commented Feb 8, 2016

@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
Copy link

mmk2410 commented Feb 8, 2016

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
Copy link

Benaiah commented Feb 10, 2016

@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
Copy link
Contributor Author

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
#28 (comment).

http://dracoblue.net

@DracoBlue
Copy link
Contributor Author

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 ;)

@DracoBlue DracoBlue changed the title Decentral Solution for @mentions Decentral Solution for @mentions or search Feb 12, 2016
@buckket
Copy link
Owner

buckket commented Feb 13, 2016

@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
Copy link
Contributor Author

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
Copy link
Owner

buckket commented Feb 13, 2016

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

@buckket buckket added this to the 1.3.0 milestone Feb 13, 2016
@DracoBlue
Copy link
Contributor Author

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
#28 (comment).

http://dracoblue.net

@DracoBlue
Copy link
Contributor Author

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

@timofurrer
Copy link
Contributor

I can have a look at it!

@DracoBlue
Copy link
Contributor Author

👍

@Benaiah
Copy link

Benaiah commented Feb 15, 2016

@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
Copy link
Contributor Author

@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
Copy link

ghost commented Apr 26, 2016

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 :/

@buckket buckket modified the milestones: 1.3.0, 2.0.0 Nov 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants