Gotenna Internet relay

Product feedback & support
1

hi,

I’ve finally played with SMS relay; just to summarize, it works as follows:

  • delivery is first attempted via Gotenna network
  • if destination is unavailable App offers delivery via SMS relay
  • app contacts Gotenna servers; they relay SMS via Twilio SMS gateway(s) (local number for me)
  • coordinates are relayed as plain text GPS, see example below
  • responses via SMS relay are not supported yet
  • senders may be using phone# or GID; recipient obviously must use number

Example of message via SMS relay:
goTenna Network Relay Message from 1415NXXXYYY
Text: text-contents
Location: username’s last location
Coordinates: 37.0000000000, -121.00000000000
GPS Timestamp: 20:15 - 15/10/17 GMT

Considering that:

  • first half of delivery is already performed via IP (origin -> Gotenna)
  • Gotenna already has some identity information for senders
  • using SMS transport adds some level of inconvenience

i believe it would make more sense to make Gotenna -> Recipient hop over IP as usual, if available.
There are a few downsides:

  • recipients need to poll for messages, potentially wasting battery; mostly a solved problem
  • gotenna needs to maintain infrastructure to support large pool of smartphone clients constantly connected
  • data coverage may be more limited than SMS (but we already rely on it to send SMS relay message out)
  • Gotenna would be able to track locations

But there are immediate upsides to consider too:

  • relayed messages would appear within same Gotenna interface/thread (not in the SMS smartphone app like now)
  • relayed messages would be no different from native Gotenna - can be replied to, can contain clickable GPS links etc
  • GID becomes first class citizen (no different from phone#)
  • this opens route for Gotenna repeater, see below
  • SMS can still be used as last resort, if recipient is not connecting via IP transport and is using phone#

Gotenna repeater, which is simply a smartphone paired with Gotenna, packed in MOAN-like enclosure, using cellular or WiFi internet, would be relaying Gotenna messages via local Gotenna coverage or IP. It’s quite similar to Internet-linked HAM repeaters, which allow to dramatically grow mesh coverage.

The downside is effort to operate directory and forwarding infrastructure, and combine IP mesh with existing mesh protocol (but i suspect some of last part can be hidden). In simpler implementation pairs of Gotenna’s apps could be linked together via IP, removing need for central directory (some effort for IP rendezvous is still required).

–igor

7 Likes
2

@sia nice thinking!
Using the goTenna SDK, anyone could build an iOS/Android app with all the features you discuss above.
@femmesh @Amon @Turnerb @kb1eea

3 Likes
3

@sia you a developer? Even if you’re not, there are devs here looking for app ideas for the Mesh SDK here: goTenna Mesh SDK talk

Regardless, backhauling into the internet is #1 on my goTenna Mesh-enabled app wishlist :slight_smile:

2 Likes
4

In my past, yes; and not on iOS/Android. I’m reviewing API… implementing described functionality (even a smaller subset) would create another silo (alt-messaging app), limiting already small Gotenna acceptance.

I’d keep looking; Gotenna Internet backhaul would be great.

4 Likes
5

Ok, we just had a discussion and friend of mine came up with the following idea - gateway between Gotenna and Signal.

Positives:

  • both are using same namespace (phone#); GID’s can be ignored (or gatewayed, if Signal cooperates)
  • this partially removes the issue with non-encrypted transport over PSTN/SMS (though security of Gotenna and Signal world is obviously different)

Problems:

  • hard to do without Signal cooperating
  • integration of Gotenna and Signal would necessarily be quite deep
  • it’s probably possible to do by using a “proxy” identity in Signal, and delivering Gotenna destination in payload; more tight integration would require Signal to trust Gotenna and Gotenna trust Signal to perform identity verification

Model:

  • gotenna app tries to deliver via radio and fails
  • it is then uses local Signal app to encrypt message, but transmits it by relaying via another Gotenna user (who has network connection) to Signal network
  • due to end-to-end nature only source (and destination/recipient) need to have Signal installed; intermediary does not need it

I guess this can be reversed around within modified Signal app, which would attempt to deliver via Gotenna first.
I’m not 100% sure if it’s still possible to use Signal in this manner though (not out of the box certainly).

1 Like
6

I know Moxie (founder of Signal) — I think they’re somewhat resource-constrained… and I think there’d have to be a lot of demonstrated demand for them to think it was worth even looking into…