Texting officially went live this morning!
You can now text by typing a 10 digit number in the to:, cc:, or bcc: field.
Some known issues:
1. Sprint-based MVNOs generally don’t work. So you can’t text Virgin Mobile.
2. Some prepaid services, T-Mobile and AT&T, do not let you respond to the SMSs you receive from Peeks.
If you have any issues please feel free to report them.
Josh B | 18-Nov-08 at 9:01 am | Permalink
Seems to work like a charm for me.
The reply to number looks like a 10-digit binary code (though given the limited number of possibilities there, I imagine it’s not that way for everyone, right?).
The only ‘hitch’ is that if the person replies back to you, you have to check for it manually (understood) and then there’s a bit of a lag (ie, for my gmail account, the reply shows up immediately on the computer, connected and logged into gmail, but seems to take a few minutes for the peek to retrieve it, even when prompted to ’send/receive’). All in all, quite nice though and hopefully a sign of things to come.
PS-would still love some type of push/OTA firmware update (my Target only had 1.04 vers). Maybe via text message attached script or something.
Josh B | 18-Nov-08 at 9:13 am | Permalink
Ok, more digging. Most of which other users may already know/understand.
Check that on a couple of things from my previous post. So, the last number of the “from” text “number” of the peek (which was previously ‘01′) is basically a marker for the text msg thread. For example, when my test phone would reply to the number the original text message would appear in the “email” that the peek would pick up.
However, if a new text is send via peek and replied to from the phone, the last digits are ‘02′ thereby counting the number of threads between the phone and my email account.
It appears then that the reply to number is simply a placeholder and that the backend of att (cell carrier) and gmail (email proxy) is working together to create a string via text messaging/email. Cool.
I’m trying to imagine how then you can set this up so that a cell respondent to a peek text can add a consistent “text to” number for the peek owner so that they can initiate a text thread.
Am I making sense here?
dan | 18-Nov-08 at 10:41 am | Permalink
The code you see is typically a session id set by the carrier’s SMS gateway. Some carrier’s pass through the email address as the ‘from’ field, some pass the session id.
They often use session ids so they can abstract out IM vs email. The session id allows the gateway to use the right protocol without having to do funky things with the from name.
Right now the only way for us to get around that gateway is to directly text customers, but that costs money per message so we wouldn’t be able to do unlimited… and we like to keep billing simple so for now that’s not going to happen.
andy | 18-Nov-08 at 1:21 pm | Permalink
Is there a way to txt Google SMS? That would be handy.
>
From local business listings to stock quotes, you can get the information you’re looking for with Google SMS.
Simply text message your search query to 466453 (”GOOGLE” on most devices) and we’ll text message back your results.
Scott | 18-Nov-08 at 7:14 pm | Permalink
Texting to a 10-digit number from peek gives me the error: “Invalid Recipient” Whoops, make sure that all email addresses have @ and symbols.
V1.04 purchased this week from target.
Tyler | 18-Nov-08 at 8:01 pm | Permalink
Google should offer an email query service..
linuxghost | 18-Nov-08 at 10:37 pm | Permalink
One of my good friends is on Virgin Mobile, and texting to him works fine using the “@vmobl.com” addendum on the end of his phone number.
Not as simple as a straightforward phone number, no, but it works fine either way/
B$$ | 29-Nov-08 at 9:32 pm | Permalink
I also got the “whoops”- Should have tested it before I cancelled Text messaging on my cell phone. Is this the software upgrade problem? If so I’m calling tomorrow monday and asking for the 1.07….
I also have 1.04