Guides

How Arnacon works

The SDK is identity, signing, and notification routing. Your app is the UI, the call stack, and the Allow dialog.

Identity is not a phone number

A user talks as an email they verify, or as a new identity they install. The name you send to is a string such as alice.arnacon.global. A phone number is not required to call or message.

TermWhat it is
Main coordinatesThe install’s wallet address. iOS getMainCoordinates(). Android getPublicKey().
Canonical nameAlways includes .global. Used for lookups, routing, and notifications. Example: alice.arnacon.global.
LabelWhat the user sees. Email, or a short name without .global.
Encryption passwordiOS gpsCoordinates. Android AppKeyManager.getAppKey. Encrypts local secrets. Not GPS. Not a number.

Resolve a name with getENSOwner. Sign payloads with signMessage / getXData + getXSign. Never log the mnemonic or the encryption password.

A product is an installed identity

The SDK calls an identity on the device a product. Installing one writes a name, a label, a state, and the service-provider metadata used later to route notifications.

  • States you will see: pending, active, inactive, failed, expired, deleted.
  • installProduct is how a new identity lands on the device.
  • New code must show an Allow. Do not auto-install from a push payload.
  • List what is already on the device with getProductsList / getIdentities.

The store apps also speak WhatsApp as a host feature. That is not this SDK and not required to call an Arnacon identity.

Notification types

From NotificationType in the iOS SDK. Android’s JAR uses the same integers.

CaseRawUse
call0Incoming-call invite. This is what rings.
message1Wake / chat notification. Wrapper sendFCMMessage.
fetch2Pull inbound payloads. Not a user-visible chat send.
fallback3Deliver a chat body after the primary WebRTC path failed.
realtimeSignal4SDP, ICE, cancel, reject, end. Must not present as a new incoming call.
deliveryStatus5Delivery / read / ack. Not user-visible chat content.

Prepare, then execute

A notification plan is a sequence of steps the service-provider contract returns. The last HTTP step is not fired until you execute.

  • prepareNotification builds the plan and returns it.
  • executeNotification fires the last step.
  • sendNotification (iOS) is prepare + execute.
  • Android sendFCMMessage / sendCallNotification / sendRealtimeSignal are the same two steps with a fixed type.

Use the plan path when you need to inspect or fail before send. Use the convenience method when you do not.

Who delivers the notification

Routing is sender-first unless the sender’s service metadata sets checkRemote.

  • checkRemote = false (or missing): the sender’s notification contract builds the plan. The target name rides in the payload. The recipient does not need an on-chain address for this path.
  • checkRemote = true: resolve the recipient with getENSOwner, then use the recipient’s contract. No address means the send fails.

You do not implement Sapphire, JWT minting, or FCM OAuth. The SDK does. If the plan fails it may retry fresh and then fall back to the GCP notification center. Treat that as infrastructure, not as something to re-code in the host app.

What the SDK does not do

If you skip these, the happy path compiles and still cannot ship.

  • CallKit, PushKit, ConnectionService, or any in-call UI
  • WebRTC / SIP media
  • Chat database and message list
  • Firebase project files
  • The Allow step before installProduct
  • Payments and store checkout
  • A public JavaScript calling SDK — it does not exist
Never:
  • Mnemonic, private keys, or the encryption password
  • Send as an identity the user did not select
  • installProduct without an explicit Allow
  • Pretend there is an API key, Maven package, or CocoaPods pod

Next

Read the method list, or go back to a path.