The accidental genius of Yo
capiche.com
capiche.com
Then the hype blew over, Parse shut down and we lost interest until I actually met the Yo CEO at a mobile event in Berlin, and after initially accosting him we ended up taking a selfie together and made up.
Anyway just a random anecdote of developers with too much time on their hands.
https://www.google.com/amp/s/www.spiegel.de/netzwelt/apps/ap...
Here's the non-Google-AMP version of your link: https://www.spiegel.de/netzwelt/apps/app-hoi-schweizer-klone...
[0] https://www.theregister.com/2017/05/19/open_source_insider_g...
/pedant
It’s still one bit. The time is not part of the transmission.
I feel like many, especially developers, fail to see what is in between the data to matter as well as the data itself. Seems like a common hole to fall into.
You as the receiver derive the other relevant information from that. A timestamp was not encoded and transmitted, a single bit (pulse) was transmitted from me to you.
That's the thesis of the article I believe. That single bit can "carry" a lot of additional information due to the context and understanding of the receiver. Information that wasn't actually transmitted in the message, but derived from it.
I mean ultimately you need to somehow map the sequence of Yo messages into "information" in a fairly precise manner. Receiving the message takes you from one probability distribution about the world -- or some particular question about the world -- to a smaller probability distribution. I'd describe the information the message carries based on that. It's contingent on what the question is.
Your latter contribution misses the mark by failing to consider that you all might just be talking past each other, arguing over semantics. That's the most common hole to fall into.
It's a 1 bit transmission with the ever-present time side-channel.
However, you're also right that the people sending and receiving the bit can derive more information from it.
I don't understand the argument here.
In order to get up to one bit of information, you need to take account of the fact that "yo" is only sent at particular times. If you ignore that fact, sending "yo" provides exactly zero bits of information, because it is the only possible message. All of the information content comes from the existence of the message; none of it comes from the contents.
So in order to claim that there's any information present at all, you have to admit that time of sending carries information. The amount of information carried then depends on the duration over which messages might have been transmitted, since that possibility is what imbues information into messages that are transmitted. It also imbues information into messages that aren't transmitted, unless you believe that a binary message of 01000110 transmits just 3, and not 8, bits of information.
The amount of information _sent_ really is 1 bit.
I'm not sure how you're calculating this, but it is obviously wrong.
The information conveyed by the contents of a message is the log of the number of possible messages.
Here, there is one possible message. The log of one is zero. There's a big difference between one bit of information and zero.
You can interpret a "yo" message as conveying one bit of information, and the only way to do that is to draw it from the contrast between "sending a yo" and "not sending a yo". If you do that, "sending a yo" sends one bit of information, and "not sending a yo" also sends one bit of information.
Thought experiment: with three bits of information, you can disambiguate between eight possibilities. Try to design a protocol in which, by sending up to three "yo"s, you achieve 8 distinct messages.
If you want to get into the topic of Shannon entropy, then that's another conversation.
You're the one who's confused. Show me how you get more than zero bits out of the content in transmission.
If you actually try to work this out, you will notice immediately that it can't be done.
Log base 2 of 1 is 0.
I thought you were continuing OPs line of thought and arguing the message contained even more bits of information.
My main point was about the side channel so I just took their word on that.
{
to: 12,
from: 15,
messages: [
1604885969953,
1604885969964,
1604885969973,
...
]
}
The message is "factored out" and contains no information since it's the same every time.Bold assumption :)
Most Yo users are not performing code reviews when sending and receiving Yos.
Let's say you send a yo now, and then you're going to send another one in 5 minutes. Then you decide to send a third in between. How much information does it contain? Less than a full timestamp's worth, because the timing is constrained.
Once you are sending yo's at the maximum line rate (certainly at least every nanosecond, it's such a critical piece of infrastructure), sending or not sending an individual yo is down to one bit of information. The time component is basically completely gone.
In other words, you cannot know the precise position of a yo at the same time as knowing the precise momentum.
I perhaps took the idea too far. Any iOS push notification can be up to 4kb, and Yo’s API shows that each Yo includes a created time, sender name, avatar, User ID, message status, and more. That’s for traditional Yo’s; newer ones can include a location or link or RSS feed item for a news update, which goes far beyond the core concept.
So on a technical level absolutely, a Yo is far more than bit. Conceptually though a single ping—a single bit—could contain the same information, like a single dot telegram, with you or your local device recording the time received. If you only Yo’d with one other person, the time and the sender and the message they intended to convey would all be data points you would assemble in your head with the ping to get the full information.
Anyhow. That’s perhaps taking the idea too far :)
Eventually I decided I like it much better this way.
I came to the conclusion that it would be a messaging system, somewhat like yo where sometimes it would send a notification even when I hadn't told it to. If you configured it so it sent an extra notification randomly for every notification you sent, then you're conveying approximately half a bit of information.
Strangely enough, I think this could be quite useful, as a way of initiating conversations with people you would otherwise lose contact with.
Of course this tactic wouldn’t work in places where the receiver of phone call has to pay a portion of the price.
Calling and hanging up didn’t count, so that is what we would do. We would know to call back.
Years later I ran reports for call centers. I would run data every which way.
Found an agent that would dial a disconnect number hundreds of times a day.
Went to big boss, as I couldn’t figure out the rational.
He took one look at it, and cursed “well know we know how he has top numbers.
Found so many ways agents would mess with metrics
For the unfamiliar, the collect call recording asked for your name and played it back to the call recipient. You had a a small window whereby you could get info across.
“You have a collect call from ‘555 4784’, would you like to accept the charges?”
Then whoever could just call you back.
The real power was unlocked with a Blue Box - a phone phreaking device that played the same tones as if money was entered into the pay phone. You could trick the phone and make your call. I remember looping the tone on a cassette tape and calling some random number in Japan for several dollars worth of tones. Good times.
- "You have a collect call from AtTheStationMyBusLeavesIn18Minutes. Do you wish to accept the charges?"
- "No"
I think frequently that the app could’ve survived and have been useful. The iterations they went through took it in less useful directions, but the idea itself didn’t need to die. Feels like a lost opportunity.
Enjoying this line from the post: "At some level of abstraction, it’s Yo all the way down."
You could definitely market it well enough to sell some merchandise or similar, it's just not going to make you a billionaire.
I also want a one-recipient-only chat app. I don't want to open Messages and 1) have to choose the recipient, 2) risk sending something to the wrong recipient.
I'd pay for that. (Anyone want to work on a feature-opt-in [no images unless both parties opt-in to images], explicit/fixed recipient chat app?)
It's pretty clear what the heart means in the context of a video call app: "I am currently thinking about you and wouldn't mind a video call, if you want to." It solves the problem of instant-anxiety of getting an impromptu video call when you weren't expecting one.
Unfortunately now you can send one of 10 different emoji instead of just the heart, complicating the feature unnecessarily by adding more bits.
This brings back memories.
Used to wear flip flops, now rare gear coppers
He's in it for the quiche
You might as well not ask him for no free s___, capiche?
Google tells me it’s “from Italian capisce third person singular present tense of capire ‘understand’”
When you say "capisc?", instead of "capisce?" (written: capisci?), Italians mostly feel that the word is said following a southern Italian dialect.
I haven’t used it regularly for years now though, but the idea’s always stuck with me.
Actually those genius level applications are not really innovative as people were spamming pokes on Facebook far before their advent
In the same spirit as the titles like “unreasonably effective”, and a few others gems.
It turns me off from the content immediately, but ‘m likely the exception.