Troveme

Proving that a smartphone is really inside an indoor space, where GPS can't reach.

No longer developed

Research and development

The problem

A restaurant wants to take orders by phone only from people seated in the dining room. A museum wants to open up some content only to visitors inside the exhibition. GPS is off by 5-10 metres even outdoors, and indoors it loses precision or drops out. A Bluetooth iBeacon is cheap, but it can be pulled off the wall and taken somewhere else, or copied. What's missing is a way to say "this phone is here, right now" that the venue can trust.

Who it's for

Restaurants and bars

They accept an order from the phone only if the customer is in the room.

Museums and cultural venues

They show restricted content to people inside the exhibition. Nobody else.

Buildings and home automation

A command, like opening the gate, goes through only if the phone is close by.

Anyone who already runs a service or an app

They add a location check with a single API and keep their user management as it is.

What it does

A code that expires

The server creates a token with an expiry for each zone and keeps renewing it. Phones inside the zone get it, phones outside don't.

Bluetooth Low Energy

Boards built on ESP32, with 1 button and 4 LEDs, broadcast the token over Bluetooth Low Energy: the phone reads it without pairing.

Copying it is pointless

We made the token originate on the server, not on the device, so cloning the signal gets you nothing. And a device that gets carried off can be shut out from the console: from then on it receives nothing.

Places as a tree

Areas, partitions, devices. Each level switches on and off with a toggle, and permissions are granted per area or per partition.

One API to verify

The service's server sends the token it got from the customer, plus the place, and Troveme answers whether it's valid. Users and rules stay theirs.

Set-up from the phone

A read-only app for installers sends the configuration to the device over Bluetooth: name, Wi-Fi network, done.

How it works

Places are laid out in the web console: areas, partitions inside areas, devices inside partitions. Each device gets its configuration over Bluetooth, from the console or the installer app, and joins the Wi-Fi. It then connects to the MQTT broker with its area's credentials, receives its partition's token and broadcasts it. The customer's app reads the token and attaches it to the request it sends to the service. The service's server asks Troveme whether that token is valid for that place. Only then does it authorise the request.

Images

Configuration diagram: the administrator creates an area, a partition and a device, then sends the configuration to the board. — Configuration

Token generation diagram: the devices ask for the token, the server takes it from the cache or creates a new one and sends it to the whole partition. — Token generation

Verification diagram: the app reads the token over Bluetooth, the service's server has Troveme check it and authorises the request. — Verification

Technical details

Technologies

Bluetooth Low Energy
ESP32
C++
MQTT (Eclipse Mosquitto)
.NET 5
Entity Framework Core
Redis
Keycloak (OAuth2)
Vue.js
TypeScript
Docker

Integrations

API REST di verifica per i server di chi offre il servizio
Accesso degli utenti con OAuth2 (Keycloak)

Where it runs

It ran as an online service made of microservices in Docker containers, with Bluetooth devices on site, a web console and a phone app to configure them.

Data and security

We kept personal data out of Troveme: the databases held places, configurations and tokens, and users were handled by a separate authentication service (Keycloak, OAuth2). Each device authenticated with the broker and only saw its own partition's messages. From the console, passwords and keys could be regenerated, which locked out the devices already connected.

Other products related to this one, and the open source libraries that came out of it or that it uses.

AddubbySmart menu for restaurants: dish cards, orders, table bookings and payments.

Frequently asked questions

Where does Troveme come from?

From Addubby, our smart menu for restaurants. To accept an order from a phone, we needed to know whether the customer was really sitting at the table. We went through three versions: first a device on every table with a display and a QR code, then Bluetooth on the restaurant's gateway, and finally a single microcontroller with Wi-Fi and Bluetooth. At that point the check could stand on its own, and it became Troveme.

Is Troveme a location-tracking system?

No. It doesn't track the people who use it, or objects, and it doesn't know where in the room a phone is. It only tells whether the phone is inside a zone where devices set up for that zone are installed.

Does it identify the user?

No, it isn't an authentication system. Whoever uses Troveme keeps their own users and rules: Troveme only confirms the location.

Why aren't GPS or iBeacons enough?

Indoors, GPS loses precision or doesn't get through at all, especially underground or across several floors. iBeacons are cheap but can be moved or cloned. Ultra-Wide Band is precise, but it's expensive, uses a lot of power and needs proprietary hardware.

Can it be used today?

No. It's a 2021 research and development project and we've closed it. The devices, the protocol and the verification method are still there: for a similar problem, that's where we'd start.

Questions about this project? Let's talk.

Write to us