4 ms·

Turn Bluetooth on. Set one device to discoverable. Send contact. Wait for approval. Enter PIN. Wait for transfer. Accept transfer. Compare to: lightly tap your

Turn Bluetooth on. Set one device to discoverable. Send contact. Wait for approval. Enter PIN. Wait for transfer. Accept transfer. Compare to: lightly tap your phones together.

jmillikin 17y ago
More accurately, based on the Bump FAQ[1]: Bump your phones together. Bump them together again. Wait for both to connect to the central Bump server, potentially failing to do so. Approve the transfer. Accept the transfer. Now, lets assume the same amount of development effort goes into writing a proper interface for Bluetooth transfers. It could be something like: Put two phones near each other. Drag an image/contact/money onto the "Bob's Phone" on my screen. Bob drags it from his inbox to wherever he wants it. That seems easier to me: it doesn't involve third parties[2], complex bump-matching heuristics, or physical contact. [1] http://bu.mp/faq http://bu.mp/faq [2] Even if Bump's servers have 100% uptime, how do you know that the local cell towers will have similar records? What if you're in San Francisco or New York, which have notoriously poor iPhone reception?
- brk 17y ago
  I think this is an excellent point. Bump is (IMO) an example of too much dependence on the "magic cloud" and an odd combination of over and under engineering. Data shouldn't have to travel to a datacenter and back to move 3 inches from one phone to another, although I can see how it's easier to leverage a cloud server for some of the functions instead of making a 100% stand-alone app.
- samratjp 17y ago
  "the local cell towers will have similar records" I didn't see anything about cell towers keeping information in the faq and why would they. Bump manages all the handshake (and probably uses something like diffie-hellman for security) and the location information seems like a secondary heuristic. I am sure Bump uses more than mere cell phone reception, for iPod Touch is supported, which means wifi must/can be involved as well. In a perfect world, yes, Bluetooth would do what it's meant to do, but in the real world people like to bump into each other :-)
  - jmillikin 17y ago
    Was my choice of words poor? I didn't mean to imply that Bump or cell towers are retaining information. Rather, I don't trust cell phone companies to maintain their infrastructure more than absolutely necessary.
    - samratjp 17y ago
      While I appreciate your sense of doubt about the cell companies, I personally wouldn't go as far without proper data on their high availability. Again, I am sure Bump has thought about this extensively enough to get some money from Sequoia.
- jeff18 17y ago
  This is a pretty loaded example. You're using the absolute worst case scenario as the use case for bumping (requiring two bumps and that their server is down). 99 times out of 100, you only need a single bump, and their uptime has been great so far!

Turn Bluetooth on. Set one device to discoverable. Send contact. Wait for approval. Enter PIN. Wait for transfer. Accept transfer. Compare to: lightly tap your phones together.

jmillikin 17y ago

More accurately, based on the Bump FAQ[1]: Bump your phones together. Bump them together again. Wait for both to connect to the central Bump server, potentially failing to do so. Approve the transfer. Accept the transfer. Now, lets assume the same amount of development effort goes into writing a proper interface for Bluetooth transfers. It could be something like: Put two phones near each other. Drag an image/contact/money onto the "Bob's Phone" on my screen. Bob drags it from his inbox to wherever he wants it. That seems easier to me: it doesn't involve third parties[2], complex bump-matching heuristics, or physical contact. [1] http://bu.mp/faq http://bu.mp/faq [2] Even if Bump's servers have 100% uptime, how do you know that the local cell towers will have similar records? What if you're in San Francisco or New York, which have notoriously poor iPhone reception?

brk 17y ago
I think this is an excellent point. Bump is (IMO) an example of too much dependence on the "magic cloud" and an odd combination of over and under engineering. Data shouldn't have to travel to a datacenter and back to move 3 inches from one phone to another, although I can see how it's easier to leverage a cloud server for some of the functions instead of making a 100% stand-alone app.
samratjp 17y ago
"the local cell towers will have similar records" I didn't see anything about cell towers keeping information in the faq and why would they. Bump manages all the handshake (and probably uses something like diffie-hellman for security) and the location information seems like a secondary heuristic. I am sure Bump uses more than mere cell phone reception, for iPod Touch is supported, which means wifi must/can be involved as well. In a perfect world, yes, Bluetooth would do what it's meant to do, but in the real world people like to bump into each other :-)
- jmillikin 17y ago
  Was my choice of words poor? I didn't mean to imply that Bump or cell towers are retaining information. Rather, I don't trust cell phone companies to maintain their infrastructure more than absolutely necessary.
  - samratjp 17y ago
    While I appreciate your sense of doubt about the cell companies, I personally wouldn't go as far without proper data on their high availability. Again, I am sure Bump has thought about this extensively enough to get some money from Sequoia.
jeff18 17y ago
This is a pretty loaded example. You're using the absolute worst case scenario as the use case for bumping (requiring two bumps and that their server is down). 99 times out of 100, you only need a single bump, and their uptime has been great so far!