@-mention when posting to Twitter

[singpolyma]

Twitter interprets microsyntax whenever you post. There's no way around it. So if you have a post whose plain text says "Blah blah with @singpolyma" there is no way to tell twitter that "@singpolyma" is not the user named "singpolyma" and it will notify said user no matter what. In a silo this works, but when bridging to a federated environment it can cause issues (and especially annoyance of Twitter users).

One way to deal with this is to have my local implementation detect any such cases and not bridge them to Twitter, but this is not ideal. What should brid.gy do if it is asked to post something with the text @singpolyma in it? Here is my proposal:

1. For the source HTML @singpolyma I would suggest changing it to "@ singpolyma", however I could see an argument to also leave it as-is, since some users might be writing plain-text microsyntax and expecting it is always going to Twitter? Hmm.
2. For the source HTML @<a href="https://twitter.com/singpolyma">anything</a> put "@singpolyma" into the tweet.
3. For the source HTML @<a href="https://singpolyma.net">anything</a> put "@ singpolyma.net" into the tweet.

Thoughts?

[kylewm]

Semi-amusing anecdata from Tantek about this: http://indiewebcamp.com/StatusNet#Syndication

Syndicating Status.net to Twitter @-mentioned @tantekcom, a twitter account that previously didn't exist

[singpolyma]

@kylewm Yes, this is exactly the sort of bug inspiring this post

[kylewm]

It's an interesting proposal; I'd say let's try a little harder to find the proper username when syndicating to twitter, and then use @ url as a pretty decent fallback.

For example, when I syndicated https://kylewm.com/2015/07/this-is-what-happens-when-you-give-me-the-keys-to my CMS saw @snarfed and knew to translate it to his Twitter username @schnarfed based on my contacts list sometimes called a "nicknames cache" in #indiewebcamp parlance.

Here's a sketch of an algorithm for how Bridgy could do this:

1. Look for @-mentions formatted like @snarfed.org, @<a href="https://snarfed.org/">snarfed</a> or <a href="https://snarfed.org/">@snarfed</a>.
2. If the extracted URL points to twitter.com, we're done.
3. Else, fetch the extracted URL e.g. https://snarfed.org
4. Look for a rel=me pointing to twitter.com
5. Use the URL to determine twitter username (optionally caching this relationship), and generate @schnarfed.
6. Else, use the literal string @ snarfed.org

This isn't an itch for me personally (I'm not using Bridgy Publish yet), but it would be a great starter project if you're interested in contributing!

[singpolyma]

How do people feel about the case where the source content contains "@BLAH" and there is no link around for context? Assume they meant twitter, or (my preference) convert to "@ blah" ?

[singpolyma]

This is complicated by the fact that by the time the content reaches granary all the HTML has been converted to text. So maybe we could do it in brigdy, but in the bridgy code there isn't a twitter-specific code path. Not sure what the right want to approach this is?

[snarfed]

good question!

at a higher level, i'm reluctant to add much (any) more sophistication or fine grained control to bridgy publish. i love that it saves you and other people from having to implement each of the silo APIs yourselves, and that you like it enough to ask for features like this! i'm not conviced it's the right place for them, though.

to do use cases like these well - choosing text to include, formatting, counting characters, interpreting (or not interpreting) mention markup - your CMS needs to integrate with them pretty tightly. you'll want to iterate on crafting tweet text, auto fill mentions, etc., which needs multiple round trips and nontrivial UI. the CMS is really the right place for all that. as a standalone service, bridgy isn't at all.

honestly, my strongest inclination at this point is to keep bridgy publish dumb, define precisely which text (etc) it takes from your post and publishes, and avoid additional functionality, since it's a losing game UX wise.

we could make bridgy publish plugins for the bigger CMSes (known, wordpress, etc), but i wouldn't personally work on those myself, and if they needed similar features from bridgy-the-service, i'd probably push back on those too.

(i'll eventually post this more visibly on my web site or somewhere, but i figured i'd start here.)

[singpolyma]

my strongest inclination at this point is to ... define precisely which text (etc) it takes from your post and publishes

That's definitely my preference as well. Users should be able to expect that bridgy will always do a single (sane) transformation in any case and if they want something different they can build it themselves.

This ticket is just about improving the sanity of the "one thing" that bridgy publishes. I think @kylewm's proposed algorithm should be simple to implement and gets us there. The only technical issue I see at this point is deciding if it should happen in bridgy (where the HTML is but the twitter-specific code isn't) or in granary (where the twitter-specific code is, but the HTML isn't). I would lean towards the latter -- I really think the HTML should go through to granary anyway (since some silos might support different formatting options, etc, doing a single hammer-transform on the HTML independent of the silo seems aggressive).

[snarfed]

i hate to say it, but i'm still reluctant. @kylewm's proposal would definitely work, but it's substantial new functionality, a new ad hoc microsyntax, and something where reasonable people could want different behavior. all of that still makes me feel like it belongs in a CMS more than in bridgy publish.

here's a straw man counterproposal: what if we support custom new webmention query params and/or mf2 classes that clients can use to give us the exact text they want to publish for a specific silo? that would relieve the pressure for complex transformations like this. sophisticated users/CMSes could use their own rich UI to craft this, then send it to us and we'd post it verbatim. unsophisticated users could keep using our existing translation. it would also let CMSes keep reusing our silo API implementations instead of doing it themselves, which i'm definitely for.

[snarfed]

also @singpolyma you and tantek should talk! he's working on the exact same thing right now: http://indiewebcamp.com/person-tag#Plain_text_authoring

[snarfed]

@kylewm and i are currently concluding (in #bridgy) that https://silo.pub/ pretty much already does what i outlined above, just via micropub. funny.

[tantek]

Way too much overthinking of casual @-mentions in plaintext (without permalinks to real world examples to substantiate above requests / algorithms). The one example given @tantekcom was 1) total edgecase (not worth writing code for), and 2) obsolete since Statusnet and identica is basically gone. GNU Social is very different today, and pumpio has yet to reveal anything similar.

@snarfed's intuition is right:

• "I'm reluctant to add much (any) more sophistication or fine grained control to bridgy publish"
• "my strongest inclination at this point is to keep bridgy publish dumb"

Twitter has basically "won" use of @-names, thus if a user types it, or sees it on TV etc. by default it means Twitter. Evidence: https://indiewebcamp.com/silo-sponsorship#US_Democratic_Candidate_Debate_2015-11-14

I use @tantek/cassis (hey how come that doesn't auto link to my repo github?) to auto_link my @-references to Twitter.

The only awkward behavior I see currently is when my posts are POSSEd to Facebook, and have plaintext (unlinked) @-mentions in them which are unclickable.

Not a big deal - never had anyone complain(*) - and because of the above (people know Twitter owns @-names) and people can copy/paste them into Twitter.com if they want.

(*)There's a comic with an oblique reference to this: http://www.qwantz.com/index.php?comic=2906
“Here's a friend crossposting from Twitter, so all these @ tags don't work.”
but that's about it.

[tantek]

Also re: person-tag - that's beyond "casual @-mentions in plaintext", where Bridgy is reading from the semantic markup of the original post "u-category h-card" etc. and then taking action. AFAIK person-tags are orthogonal to this issue.

[singpolyma]

No interested in inventing new microsyntax certainly. The whole idea here is to fix an issue with accidentally misposting of existing syntax. When a post has a specific permalink in it to specify the person being mentioned is not on Twitter, the twitter user of same name should not be notified.

Non-twitter @-names are common (including here on github and on the large and growing GNU Social networks, just to name a couple). Real-world experience with accidental mentions to Twitter among GNU social users has caused that community to disable posting to Twitter for most posts containing @-mentions.