Make @-mention configurable or optional on replies

[rlskoeser]

AFAICT, brid.gy automatically adds an @-mention when it processes an in-reply-to and there is no way to disable that. I sometimes use twitter replies to myself as a way of threading conversations / linking up posts to each other to provide context, and would very much not prefer to @-mention myself every time I do that. Is there any way to make this configurable or optional?

[snarfed]

sure! good timing, other people asked for this recently too: https://twitter.com/jkphl/status/732284815240757248 . cc @jkphl @iamwebrocker

they confirmed that @-mentioning yourself is optional, and twitter still interprets it as a reply without the self mention, so i'm inclined to just drop it altogether in that case.

should be a pretty straightforward change. @rlskoeser any interest in tackling it? dev setup instructions here, code change probably here.

[rlskoeser]

@snarfed is it just a matter of removing that highlighted code section, then? And perhaps documenting somewhere that users who want to @-mention in replies should do so explicitly?

I'm interested in contributing, but I'm just getting started playing with brid.gy and web mentions as a side project and don't know how much time I'll have or how soon.

[snarfed]

@rlskoeser not quite that easy. we want to keep that code, since it's including the @-mention for normal replies. we just want to add a special case to omit it when it's yourself.

no worries on timing! feel free to jump in whenever, if i haven't gotten to it first. :P

[rlskoeser]

Yeah, that makes more sense now that I think about - and I see there is some logic to only add the mention when it's not already included in the text somewhere.

Where would you access / determine the current user's twitter handle?

[snarfed]

yup, good question. you could brute force it with get_actor(), but that makes another API call, which sn't a big deal, but might be nice to avoid.

bridgy knows their handle, so it could pass it in. or it could pass a new boolean mention_user kwarg (or something) depending on whether it's a self reply. or something. i guess i don't have a strong opinion yet.

[kylewm]

Another option might be passing the screenname in granary.twitter.Twitters constructor, where it gets the auth tokens.

Has the advantage of being specific to Twitter rather than adding a property (or **kwargs) to all 4 services' create() and preview_create() methods

Disadvantage of being less functional, adding complexity to the Twitter class.

[iamwebrocker]

hi,
I think it is a good idea to tie this to the twitter integration. and it would be great if it could also discover if one wanted to self @-reply on purpose. so I think the logic should be something like this:

• make note of the author's handle
• if the reply is a reply to a tweet of the same author, and the author's handle is not anywhere in the tweet, make a reply without @-mention
• else look for a handle inside the tweet, if not found, add the handle of the tweet this is an reply to the front of the reply, if found, do the reply

or maybe simpler:

• if this is a reply, look for handle(s) in the text. if found, do nothing. (so this could include the own handle as well - this way one could @-reply to oneself on purpose)
• if no handles are in the text, and the reply is to a text by the same author/handle, do nothing
• if no handles are in the text, and it is a reply to a different author, than add the handle to the beginning of the tweet (I think this is the current behaviour)

great to see that this is on the radar now :)

[snarfed]

@kylewm true, thanks!

@iamwebrocker definitely! that's basically how it works now, we just need to stop adding the @-mention if it's yourself. thanks!

[snarfed]

had some downtime. enjoy!

[rlskoeser]

@snarfed this is great, thanks! I've looked over how you implemented it, so maybe I'll be more comfortable helping out on something else.

I've just used it, looks great!

Question: how often do you push updates to the live brid.gy instance? Do updates go live pretty much immediately? I don't see any mention of that in your docs, and don't see any tagged releases or version numbers or changelog to help with figuring that out.

[snarfed]

@rlskoeser glad to hear it!

much of the heavy lifting in bridgy happens in the granary and oauth-dropins libraries, which definitely have versions and release notes. bridgy doesn't, though, since it's an end user service and we're lazy. :P

we pretty much deploy on every meaningful change. test coverage is pretty good, which makes us comfortable with that without a lot of manual QA or heavier release process. i'd actually like to set up continuous deployment, which shouldn't be too hard: #668.

if you want to know what's happened recently, the commits and issue updates are both decent ways, if not ideal.