It's probably so that people don't accidentally publish something they intended to DM by tapping the spacebar twice after the command. It'd still imagine it should be allowed from a full keyboard, at least.
Nice idea, but 'internal server error' (per the linked tweet, didn't try it) isn't exactly a good reaction. IF someone thought that this might make sense, the result should not/would not be a 500..
yes, absolutely! It has to be this. Plus, a tiny little period is really hard to miss on mobile (where the shortcut you mention applies). it's almost justified.
"d. something" is not the only offender. I suspect it's a badly written parser. "m. anything" also breaks. And for fun, without the following word ("something"), the tweet just vanishes with no error at all.
I tried all of the non-space non-alphanumeric characters on my keyboard. Some worked, most caused an error.
Anyone remember Anthony Weiner? His infamous tweet (that ended up with him resigning from Congress) was intended to be a direct message but he started it with @, not D, so it went (briefly) to his public timeline [1].
And it seems that, when you're a congressman, posting a dick pic even briefly is enough to attract some attention.
I'd guess this is related to the in-band use of 'd nickname" to send a direct message. Which is also a bad idea, since that makes it too easy to accidentally make a private message public.
"Note about DM fails: Your service provider may split SMS messages greater than 160 characters into multiple messages. In this case, the second message will post as a normal Tweet because it doesn't begin with d+username, as the first message did. Please be careful to ensure that your messages are under 160 characters."
reminds me of the shitty email filter the school I taught at back in the late 90s used. It would filter out curse words but it ignored spaces so if you typed something like "push it" is would see "sh it" and delete those letters. It rendered your emails basically unreadable.
Magically aligning a perfect string at a 160 character offset, and somehow have it being a user who would have any idea about what you're discussing? A total non-problem.
I'd be really interested to see how many users still use the SMS interface. I switched away from it as soon as I got my first smartphone and haven't looked back.
My guess is that the number has recently increased, with most phone plans now offering unlimited talk+text but metered data. On a prepaid plan, when you've run out of data, some carriers will just do a hard stop on your data and others will reduce it to a slow trickle, so the SMS interface might be the best.
I very much doubt it. Using Twitter is such a way would be absolutely awful these days, and few people (outside of the tech bubble) hit their data plan limits.
It's not about how much data it hogs -- it's that for prepaid plans (which are the vast majority of overall subscribers worldwide), when your data runs out it often just completely turns off until you get another top-up card.
Ha. I now have a throwback to my earlier days, when I subscribed to Ron Paul and I used to get all his tweets as messages on my dumbphone. And I read each single one.
Luckily, I bought a smartphone later and stopped being a libertarian.
I'm from Poland. We have Donald Tusk (D. Tusk) here, who is the President of the European Council since 1 December 2014, and previously he was Prime Minister of Poland from 2007 to 2014. It would be funny if that had any connection to this issue.
That's how I noticed. I tried to tweet something about Donald Tusk and had to abbreviate his name because of the length. I know about the "D handle" prefix but apparently it also triggers for "D. handle" which is why I wrote about how I dislike in-band signalling.
For those commenting about why you would want to do this in the era of smartphone and apps: its useful in areas of low bandwidth.
I'm in IL typing this from a 2G mobile network. It's painfully slow, the data connection goes in and out. Loading my Twitter app is a feat of patience.
SMS works fine though, and getting and sending messages via 40404 is easy. If this is how you're used to using Twitter, why shouldn't you be able to interact this way on the web?
From the Twitter help center: "Note about DM fails: Your service provider may split SMS messages greater than 160 characters into multiple messages. In this case, the second message will post as a normal Tweet because it doesn't begin with d+username, as the first message did. Please be careful to ensure that your messages are under 160 characters."
Twitter doesn't have multipart SMS reassembly? Twitter advertises that the size limit for direct messages is now 10,000 characters.[1] But apparently you can only send big from their app, or when advertising ("sponsored tweets"), not from SMS.
Multipart SMS reassembly isn't all that hard; every smartphone does it. Messages are split into 153 byte fragments with a binary header, with a max of 255 fragments. At Twitter's scale message parts may come in to different front end machines, which means having to reassemble fragments across multiple processes/machines. Most SMS gateways don't reassemble fragments on inbound because of that scaling problem, but Nexmo and Twilio will pass through the fragment numbers so you can do it. (This is a new Twilio feature in beta. Ask Twilio to turn it on if you need it.) Outbound, SMS gateways almost always handle multipart. Have to be able to send big ads in bulk, after all.
While the ordering of messages is part of the protocol, it's not a required part - there's no guarantee that a phone will correctly indicate the number of parts of the message in the header(s).
Given that, I'd rather say "this feature will fail in this way" than "sometimes, depending on your phone and carrier, your long SMSs may be split into multiple parts, the second of which will posted as a public message".
For GSM, number of parts is a required item in the multipart message header.[1] It's field 5 of the UDH.
Some phones have had trouble with reassembly. There's an old Android bug which manifests as a new incoming message being reassembled with parts of an old one, sometimes an old one from months ago.[2][3] That indicates a broken reassembly implementation. It's easy to see how that can happen. The "unique ID" on multipart messages is only 8 bits (16 bits with an alternate header format). That number is generated by the calling phone. Unmatched fragments should be discarded (or delivered as an error) after a few minutes. Android keeps unmatched SMS fragments for the life of the phone, resulting in the occasional reuse of long-forgotten message fragments. Worse, when this happens, when the correct fragment comes in, it's saved as an orphan. So once there's been an orphaned fragment, 256 long messages after that, there will be another bogus reassembly using the old fragment, with the correct fragment being saved as a new orphan. Some users changed their phone number to get around this bug.
Google's reaction to years of bug reports on the problem was to close the bug report as "Obsolete" without fixing it.[3]
To work around this botch, there's an app: "SMS Multi-Part Cleaner". Really.
"For GSM, number of parts is a required item in the multipart message header.[1] It's field 5 of the UDH.
"
number != order.
As said, sms's are not guaranteed to be received in a particular order, nor is the order recoverable (because the clocks are not guaranteed right, etc, so even sorting by time, ...)
Read the spec. The header on each multipart message fragment has the number of fragments, the fragment number (counted from 1, for some reason), and a semi-unique ID generated by the sending phone. You also get the source phone number along with the message. This is sufficient for correct reassembly.
The semi-unique ID is normally only one byte, and so old unmatched fragments can match new messages. Android keeps old unmatched fragments in a database for the life of the phone, which is insane. (We drop them after 5 minutes in our system. A more conservative approach would be to wait until a successful message from the same phone, indicating communications have been reestablished, and a few minutes after that, purge old fragments from the same source.)
If you have your own system which doesn't send UDH headers, and you can't reassemble, it's your problem. SMS messages are not ordered, but then can contain ordering info.
The major smartphones all send UDH headers, which have enough data for reassembly. At least if you don't keep old fragments for insanely long periods.
One trick for faking out various tweet parsing is U+200B, Zero Width Space. I use it a lot to tweet domain names without them being turned into t.co links. There should be one for you to copy and paste here >< there.
Whats the intended use case for having this character in the first place? It seems like you could use it in a whole bunch of places to bypass regex/classifiers, or potentially a lot of things without proper encoding. I could potentially register at NelsonM<>inar somewhere and who would know the difference at a cursory glace?
Lots of services limit usernames to a certain range of characters, but some don't. However, there's tons of invisible unicode characters that you can use instead, so even without this one, the problem would still exist.
Thеrе arе many cyrillic lеttеrs looking idеntically to latin lеttеrs. In previous sentence all "e" letters were cyrillic, for example. So probably the only sane way is to limit username characters to latin letters.
Just like all the other spaces and zero width characters[1], it's originally for typography and typesetting. It is used to create word boundaries so that text would break at the right places in paragraphs, but without creating the visible, well, space between words.[2]
Wavelength of 2600Hz at 44100Hz sampling rate would be slightly under 17 samples, so any repeating string of 17 single-byte characters would do (44100/17 = 2594Hz, dunno if that's close enough). Or 34 or 68, depending on whatever is playing it expects stereo and/or 16-bit data.
Unless the higher harmonics (5200Hz, 7800Hz, etc) mess up the tone (no idea how strict the old 2600Hz hack used to be). In which case you need some characters that approximate a sine wave. Which isn't too hard, given that you don't care about DC bias and max amplitude.
Somewhere someone is finding a way to make this a buffer overflow. Wonder how long this will take to get fixed. I totally forgot about Twitter's in-band and SMS features until now.
[1] - https://support.twitter.com/articles/14020