Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
@-mention when posting to Twitter #527
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:
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
For example, when I syndicated https://kylewm.com/2015/07/this-is-what-happens-when-you-give-me-the-keys-to my CMS saw
Here's a sketch of an algorithm for how Bridgy could do this:
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!
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?
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.)
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).
referenced this issue
Nov 20, 2015
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.
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:
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
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.
referenced this issue
Nov 24, 2015
should have added this link here a while ago: https://snarfed.org/2015-11-29_keep-bridgy-publish-dumb
This was referenced
Aug 11, 2017
I voted for an option to post plain text.
The original text:
added a commit
Nov 22, 2017
(continue to follow here?)
The plugin unticked 'Set twitter from post excerpt'
If I preview the post in brid.gy, it can consume the