Locality Lemma 1

Locality Social Cloud is an application of an interesting mathematical result; the Fundamental Theorem of Locality Calculus. This enables realtime computation to be distributed across client devices, verified by redundancy, and scaled by checkpoints, without a central authority. As an application, we present a multi-tenancy end-to-end-encrypted scalable realtime distributed consensus platform.

How to obtain a backend

For testing purposes, you can use the public test realm

    realmId: "public_test_realm",
    realmSecret: "Zmbw951fsRPhCPake6rtBWc8YPKvUYChi45gN14znek=",

or create your own realm at https://localitysocial.cloud. It is possible to license the backend. Furthermore you can obtain physical servers running the Locality Social Cloud at https://localitysocial.store. These servers are optimized for low energy cost. Your servers can be connected into a distributed system. This allows you to upscale your operations.

Social Apps

Locality Social Cloud was primarily built to simplify the development of end-to-end encrypted social apps. Social Apps are fundamentally a technological reflection of real social interactions. In real social interactions, we interact through objective space that transports state changes at light speed. The challenge of creating objective spaces for multiple observers across many devices is fundamental. Locality creates an isomorphism between real-life social interactions and its model in code.

Traditionally, state management and business logic are performed on servers. This creates unsurmountable challenges when dealing with End-to-End-encrypted interactions. With Locality Social Cloud, you can create serverless Social Apps and model all your domains on the frontend. This allows for improved flexibility when building or updating features (no deployment) and allows you to develop Social Apps in a way where the problem modelling just fits the problem space more naturally.

Quickstart in Flutter

Add the locality_social_cloud library to Flutter

Write

flutter pub add locality_core
flutter pub get

to add the Locality Social Cloud to your Flutter App.

Configure Locality Social Cloud

Obtain your app-ID and app secret from your developer account and write

await LocalitySocialCloud.startTest(
    userCredentials: UserCredentials("Malte", "123456"),
    developerCredentials: DeveloperCredentials(
        realmId: "YOUR_REALM_ID",
        realmSecret: "YOUR_REALM_SECRET"
    ),
    isRegistration: false
);

to set up your social cloud in test-mode. If this code is performed on a user device, they obtain your realm id and secret. In production, you would use

    cloud = await LocalitySocialCloud.start(
        userCredentials: UserCredentials("Malte2", "1234567"),
        localityTicket: Ticket("value"),
        isRegistration: false
    );

while your own backend acts as a man-in-the-middle to issue a Login-Ticket to a user, without exposing your realm secret. For more information on this, see # Obtaining a ticket in production.

Supervise your first PubSub

First, use the mixin PubSub to write a class that is model, view-model and controller at the same time.

class DistributedMobBoss with PubSub {
  String name;
  double hitPoints;

  DistributedMobBoss({required this.name, required this.hitPoints});
  
  @override
  String getTopic() {
    return "$name-boss-state";
  }

  @override
  void onReceive(Broadcast localityEvent) {
    switch ( localityEvent.event ) {
      case 'attack':
        hitPoints -= localityEvent.getPayload()['damage'];
        break;
    }
  }
  
  void attack(double damage) {
    send('attack', {
      'damage': 10
    });
  }
}

Next, supervise your PubSub

DistributedMobBoss herbert = DistributedMobBoss(name: "Herbert", hitPoints: 1000);
LocalitySocialCloud.supervise(pubSub: herbert);

You have now created a distributed mob-boss! When any player on any device deals damage to Herbert, his hit points get updated on all devices.

Commit your first engrams

Finally, you are ready for the Endgegner with 1000000 health.

DistributedMobBoss brudwilda = DistributedMobBoss(name: "Brudwilda", hitPoints: 1000000);
LocalitySocialCloud.supervise(pubSub: brudwilda);

Because Brudwilda has so much life, thousands of events are needed to kill her. But we only want to store a single aggregate number. To make this performant and have Brudwilda live for years, change the method signature to

class DistributedMobBoss with PubSub, Cumulonimbus

and override the method initializeFromEngram

  @override
  Future<void> initializeFromEngram(Engram engram) async {
    if ( engramContent != null ) {
      hitPoints = jsonDecode(engramContent.serializedData)['hitPoints'];
    }
  }

We write a little helper

  Future<void> commit() async {
    sendEngram(jsonEncode({
        'hitPoints': hitPoints
      })
    );
  }

And now we can go

brudwilda.commit()

to send an engram. This will create a potential consensus point. Once sufficient amount of people have reached the consensus point, instead of fetching the whole past, Brudwilda will be directly initialized from the last secure consensus point and load only events that happened after. This guarantees a long life of Brudwilda.

How to think

All end-users share a 'current state' per channel in realtime. The 'current state' is the functional integral of all past state changes. All computation is done on user devices, verified by redundancy and scaled by checkpoints.

This leads to some nice patterns for software development

Event-sourcing

Locality naturally implements Event-sourcing, as described in https://martinfowler.com/eaaDev/EventSourcing.html.

Distributed Aggregator

Use engrams to provide secure entry points for event sourcing without replaying the whole past. This is particularly useful for sigma-subadditive state. That is state where the memory-footprint of an Engram is smaller than the sum of memory-footprints of past state changes. The first class of problems to use Cumulonimbus for are aggregate computations (like counting events, computing averages, keeping track of hitpoints of a distributed mob boss), further, computations that can undo and overwrite past actions (like collaborative image drawing on a canvas, shared 3D-model deformation, friend/unfriend and block/unblock features, ... ) should use Cumulonimbus and finally, computations that happen under adverse conditions (like flaky sensor arrays).

User-Action-Isomorph pattern

Each user action - characterized by the user performing a physical action - corresponds to one event type. All other application state can be derived from these events.

ViewModel Accumulator

With Locality Social Cloud, a seperation between controller, service and viewmodel is no longer useful. The same class that sends events also processes events and notifies the user interface about state-changes.

Contact

Enterprise inquiries: legal@locality.media

Libraries

locality_core