Iceblock SDK

An app's life

An app built on Iceblock works whether or not its user has Iceblock. It goes through up to three stages, and it keeps its data through each.

1. Alone

Built The first time the app starts the library, it’s a network of one device: it makes its own keys, and it’s that network’s founder, at Full trust. Everything works there: Collections, versions, encryption, the store on its disk. Nothing is copied anywhere else yet, because there’s nowhere else.

The app keeps its files in a Collection of its own, made when it starts.

  • The same app on the user’s other devices (their phone and their laptop, say) joins that network by ordinary pairing: one shows a link or QR code, the other opens it. Built
  • Then each device holds and copies the Collection as Iceblock’s own devices do, over the local network, or through a relay when they’re apart. Built

2. Sharing with other people

Built in the core, through a group: the app makes a group, with its network the group’s home and Owner, puts its Collection in it, and invites other people’s copies of the app with a link. Each joins with a role:

RoleCan
Memberread the group’s Collections
Contributoralso add, change and delete files (to the trash)
Caretakeralso make Collections, invite, and manage the members below them
Ownereverything: deleting Collections, purging the trash, the group itself

Roles can differ per Collection. The group’s home keeps its Collections safe, at their level. Members’ devices hold the Collection together with it: they keep what they open, or whole copies if they choose to, and their changes go to the home and on to the others. Members can also lend the group storage. An invitation can need approval, and the home then asks an Owner or Caretaker.

Plain shares (a link to a file or folder) exist too, Built, but a share’s link names the network that made it, and that network goes away if the app is adopted (stage 3). A group survives that, once the gap below is closed, so the SDK steers apps to groups. Open whether the SDK offers plain shares at all.

3. Joining the user’s Iceblock

When the user has Iceblock, the app becomes an app device of their network: Scoped trust, holding only the Collections it’s given. It never holds the network’s root keys. There are two ways in:

  • The user already has Iceblock. The user’s Iceblock shows an invitation, and the app opens it (scanning its QR code); Iceblock asks, and the user chooses “an app”. The app joins at Scoped, with nothing in scope, and asks for the Collections it needs. Built On the same phone, the two apps can do it directly, without a QR code (the package). Built, on Android, in r84.
  • The app has its own data already. The same pairing, but the user’s Iceblock carries the app’s network in (a pulled merge): its files land in a Collection of the user’s network, and the app keeps it in scope. The app’s keys never cross into the user’s network; the user’s device does the carrying. Built

What adoption brings:

  • Built, in r76: the app’s network and groups handed over. Adopting the app ends its own network: before it goes, it signs, with its own key, that the user’s network succeeds it, and that key is destroyed. A group whose home it was has the user’s network as its home, in the app network’s place with its role; a group it belonged to takes the user’s network in its place. Other members, looking for the old home where it was, are shown the succession by any of the user’s devices, check it, and carry on from the new home, reading what’s written since. Nobody has to do anything.
  • Built, in r76: several of the user’s devices with the app. Adopting the app through one of its installs brings the others too, pre-approved as app devices of the user’s network holding the app’s Collection. Each, meeting an install that has already moved, learns where to go, and is moved over by one of the user’s devices; its copy of the old network’s key goes then. Installs of the same app sync their Collection with each other directly.
  • Built, in r76: an Applications section under My network: each app, its devices, its Collections (opened from there), what else it holds, each of which can be taken back, what it may ask for, and the groups it’s in.
  • Built, in r76: hiding an app’s Collections from Files. Shown by default: an app may want a folder the user also opens directly, such as photos. The app can ask to hide one (hide_from_files), and it’s then kept out of Files and Collections, shown under the app instead; the user can change it there.

After joining

An app device:

  • reads and writes the files of its Collections, and only those: it’s sent nothing of the others, not their files, documents or keys; Built
  • holds a view of the network rather than its document, made for it at each sync by one of the user’s Full-trust or Metadata-only devices: the devices’ names only with devices, and nothing of other Collections, not even that they exist, without collections; Built, in r76 (the first app’s needs)
  • asks for another Collection, which the user approves or denies, once or always; denied once, it may ask again after a cool-down that doubles each time; Built
  • isn’t counted on to keep copies for others, and holds what it works on; Built
  • can’t run a group itself (that takes Full trust): the user’s network runs the group from then on. Changes to the group go as requests the user approves (group:<id>); it reads its groups through the user’s network, in its view of it (Built, in r81).

The user can remove it at any time, as any device, and its keys are changed so it can’t read anything new.