Locality Lemma 1

A minimal, elegant, production-ready realtime backend for distributed computation.

Locality Social Cloud is an application of an interesting mathematical result — the Fundamental Theorem of Locality Calculus. It enables realtime computation to be distributed across client devices, verified by redundancy, and scaled by checkpoints, without a central authority.

Realtime · Scalable · Decentralized · End-to-end encrypted · General computation
Start Developing
Introduction

Where Bitcoin meets Cloud.

Both are but incomplete solutions to the problem of consensus in distributed systems.

Bitcoin

The Bitcoin protocol can reach consensus in distributed systems without central authority, but it lacks general computation and realtime capabilities.

Cloud Providers

Cloud providers have general computation, but force trust in a central authority and Vendor-LockIn.

As an application, we present a multi-tenancy end-to-end-encrypted scalable realtime distributed consensus platform — a platform without Vendor LockIn that can be hosted on your own hardware, with a fair license.

(1)Realtime
(2)Scalable
(3)Decentralized
(4)End-to-end encrypted
(5)General computation

This solves several long-standing hard engineering challenges. To know more about the license, view the License section or read LICENSE.md.


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.

The Consumer App
Scalability Dilemma

Classically, a founder of a social network has a very hard trade-off right at the start of their journey: Cost. Social Apps can go viral and explode in computation demand. But existing cloud providers demand a large margin. Countless developers went broke from their cloud bill, after what should have been their success — product market fit.

On the other hand, writing scalable and cheap distributed systems is very hard. They take away significant time and resources that the founder wants to direct at achieving a product-market-fit. So while the first type of social app developers go broke, because of their success, the second type of social app developers might build a system that scales to millions and is used by no one.

  • (1)If they focus on the product and delegate the hard problems of distributed systems to existing cloud providers, they risk being broke — and even if not broke, it forces them to redirect the cost to the user, somehow. While existing social networks can make tens of dollars per user per month using advertising, they can't provide users with a cheap enough subscription that would warrant their cost and be accepted by users at the same time.
  • (2)If you focus on the technology and solve the hard problems of scale and distributed systems, significant upfront cost and investment is necessary without any knowledge of whether users will accept the product. This massively increases the fixed cost and initial investment to build consumer apps that scale.
  • How Locality Addresses
    the Dilemma

    Cost for developing social apps comes in forms of development cost and maintenance cost. Locality Calculus allows traditional backend logic to be performed on the user device. This minimizes development cost by obsoleting backend development and deployments for updates.

    Traditionally, handling state synchronization, race conditions, and merge conflicts when users cycle between offline and online states require careful engineering. By treating state mutations as deterministic sequences of a functional integral, Locality ensures seamless, conflict-free synchronization out of the box — even in zero-trust, end-to-end encrypted environments.

    Locality Social Cloud was built on Elixir, OTP and the BEAM VM. Scaling a distributed system under time pressure is a pain that Locality Social Cloud alleviates; partial system failures are handled gracefully. Adding and removing additional machines to scale your network is a matter of a single command.


    Take now this Ring… for this is the Ring of Fire, and herewith, maybe, thou shalt rekindle hearts to the valour of old in a world that grows chill.

    How to think

    Patterns for software development.

    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.

    martinfowler.com/eaaDev/EventSourcing.html

    Event-sourcing

    Locality naturally implements Event-sourcing, as described by Martin Fowler.

    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 — 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 separation 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.


    Client Libraries

    Flutter and JavaScript.

    A minimal setup for any client library would include:

  • (1)The elliptic curve M-511 provides public/private keypairs for secure key exchange between users.
  • (2)Token exchange protocol is implemented.
  • (3)As an abstraction of Phoenix Sockets, you work with a throttled observable 'Cumulonimbus'. The Cumulonimbus receives LocalityEvents (payload, timestamp, signature…) emitted by the "send" method, computes a state change and notifies UI listeners. It is therefore a bridge between User-Input and User-Viewed-Reality. Additionally it decides when to commit engrams (a snapshot of the current state) via "put_engram".
  • (4)First, use "fetch_engram" to find the sequence_id of the last known consensus point.
  • (5)Next, use "fetch" to fetch all the missing messages since the last known consensus point.
  • (6)When messages are out of order or missing, hold back before you notify the UI.
  • (7)Local caching minimizes data transfer.
  • Note

    A Cumulonimbus is guaranteed to receive each event by each user exactly once and in the correct order. In order to write custom client libraries, (2)–(6) are mandatory, while (1) and (7) are strictly recommended. Without (1), the server can decrypt event data. Without (7), maintaining the full history of long lists that can not be compressed requires re-fetching data.


    Quickstart

    Building a distributed mob boss in Flutter.

    Add the library

    Write the following to add Locality Social Cloud to your Flutter app.

    shell
    flutter pub add locality_social_cloud
    flutter pub get

    Configure

    Obtain your app-ID and app secret from your developer account at locality.media and write the following 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.

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

    In production, you would use the following, while your own backend acts as a man-in-the-middle to issue a Login-Ticket to a user, without exposing your realm secret.

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

    Supervise your first PubSub

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

    dart
    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.

    dart
    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 1,000,000 health.

    dart
    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.

    dart
    @override
    Future<void> initializeFromEngram(EngramContent? engramContent) async {
    if ( engramContent != null ) {
    hitPoints = jsonDecode(engramContent.serializedData)['hitPoints'];
    }
    }
    
    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 a 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 deploy

    Bare metal, one binary.

    Locality Social Cloud is an Elixir based system designed to run as a distributed system on Linux-based systems and can be installed and configured as a debian-package. It is built using mix release, which packages it as a self-contained binary. The only dependency is postgres.

    It is recommended to be deployed bare metal. No nginx. It runs its own cowboy server and has its own TLS security layer. A locality.service is included that provides additional security layers, such as complete sandboxing of the service. All configuration is done via environment variables; they can be sourced from locality.env.

    Installation

    Installation will prompt you to review and change all desired environment variables and configuration. A hash of your master password will be stored in the linux keyvault and the configuration file will be signed. Passwords needed for the shared system to run will be derived from the master password.

    CLI
    $locality install
    $locality --version
    $locality start
    $locality stop
    $locality config
    $locality man
    $locality help
    $locality license

    Scope and Limitations

    The simplified Byzantine General Problem.

    Data integrity in distributed systems under adverse conditions leads to the byzantine general problem. Locality Social Cloud achieves its massive performance and architectural simplicity by introducing two core assumptions that separate it from protocols like Bitcoin.

  • (1)No sybil attacks.
  • (2)The server's "timestamps" (sequence ids) are trusted.
  • This is a trade-off. Bitcoin goes to extreme lengths and incurs massive energy costs to decentralize and randomize the timestamping authority, because timestamping is critical to prevent double-spending in a global financial ledger.

    In the context of social interactions, however, Sybil attacks and timestamp manipulation represent entirely different threat vectors. While Sybil attacks are a massive theoretical threat to decentralized consensus, in practice no one wants automated bots participating in a high-fidelity social network. The core engineering challenge is therefore reframed:

    Each user has exactly one identity and is a real person.

    To ensure that each user possesses exactly one identity and corresponds to a real person, Locality delegates this responsibility to an external Authentication Context. By decoupling identity verification from the state engine, you can tailor Sybil resistance to the specific domain.

    Sybil resistance, by domain

    State-issued pseudonymity token — imagine that, when voting, you get issued an invitation token. This invitation token can be exchanged for a pseudonym. This ensures that the Social Cloud is filled with real people, while anonymity is guaranteed.

    Company context — in internal tooling for companies, limiting access to employees automatically excludes sybil attacks.

    Social Apps — it is up to you how to determine that a user is a real person. The most secure choice is to only allow invited users into the network and to issue invites only personally, for example as QR-Codes.

    By assumption of the no-Sybil-condition, the difficulty of the byzantine general problem is entirely shifted to the authentication context, which is way easier to solve. The "trust of timestamps" is a more theoretical than practical issue. In practice, users can verify if messages are missing, due to hash-chains stored in user-sent events. Additionally, messages are timestamped by users and end-to-end-encrypted. Computation is entirely done on the user device.

    The remaining attack vectors include conspiracy between users and Locality Social Cloud owners. The limit of this conspiracy is the reordering of messages within a short timewindow — exactly the same limitation Bitcoin has. In Bitcoin, solving a hard problem gives you timestamping authority: the exact timestamp, the transactions included within a block, the ordering of messages, remains in the power of the 'miner'. The only additional security guarantee this protocol gives within this domain is that a timestamper is randomly selected; the "conspiracy" is financially incentivized by transaction fees. In Locality Social Cloud, data-integrity is ensured by independent computation and Cumulonimbus-checkpoints.


    Integration

    Secure multi-tenancy.

    Secrets can only be created by localhost. Each secret defines its own 'locality'. Data are separate between localities. One secret can issue 'tickets' to multiple users. These 'tickets' allow the user to perform an authorization request. If successful, they will receive a stamp that can be refreshed. Stamps are what the user needs to access the websocket-api and to perform and request broadcasts on topics.

    Developer Platform

    You could build a developer platform. It would interface with the API on localhost to create secrets, keep track of which secret is assigned to which developer. The developers can then use the secret to obtain tickets and redirect these keys to users, so they can log in.

    Consulting

    You use Locality Social Cloud in multiple customer-related projects. Each customer realm can receive their own secret. This keeps their data separate, but you only need to host and manage ONE Locality Social Cloud.

    Secure Cross-App Collaboration

    Using the same secret and realm to issue tickets to multiple different end-devices allows these apps to collaborate in a closed ecosystem. This way you can reuse features across apps without losing security.

    Space Resilient Networks

    Space is not friendly to computers and hits them with 'cosmic rays'; this leads to computation errors and hardware degradation over time. Run clusters of Locality Social Cloud to ensure resiliency of computational hardware under adverse conditions, such as space, nuclear war, alien invasion or AI apocalypse.


    Root Access from Localhost

    API Reference.

    GET /root/realm/list

    List all realms.

    POST /root/realm/create

    Parameters: realm_id. Create a new realm. Returns a JSON with realm id and secret.

    payload
    {
    "realm_id": "Locality Three"
    }
    answer
    {
    "realm_id": "Locality Three",
    "realm"   : "oDpqd0PJSIf9CHIbNTCpbCQhFigFwB5t/Jy4bR2UlcE="
    }
    POST /root/realm/secret

    Retrieve a secret for a realm with a list of given IDs. Expects a list of IDs as JSON ("realm_ids").

    payload
    {
    "realm_ids": ["Locality Two", "Locality Three"]
    }
    answer
    {
    "realms": [
        {
            "realm_id": "Locality Two",
            "realm": "7ZwPpBBDcO5HczN9OeT1NhBBTLhPVqRHeEwRxFYTOFc="
        },
        {
            "realm_id": "Locality Three",
            "realm": "oDpqd0PJSIf9CHIbNTCpbCQhFigFwB5t/Jy4bR2UlcE="
        }
    ]
    }
    Realm Access for Secret-Holder
    POST /locality/issue-ticket

    Expects payload to be signed with a secret. Creates a ticket that a user can log in with. Expects request to contain timestamp and target user ID in JSON. The ticket has a lifetime of 300 seconds.

    header
    {
    "x-realm-id": "Locality One",
    "x-signature": "821a1327d2e2c5bad31c332c41d9f1e29f82421cf852bcb83f704d99582137da"
    }
    payload
    {"user_id": "Malte"}

    For testing purposes it is recommended to omit unnecessary whitespace in the payload, as it may create invisible characters that change the HMAC-signature in subtle ways — for example, Postman adds escaping characters like \r and \n to the payload. A SHA256-HMAC for testing purposes can be created with online tools such as devglan.com's HMAC-SHA256 generator.

    answer
    {
    "token": "SFMyNTY.g2gDdAAAAAJtAAAACHJlYWxtX2lkbQAAAAxMb2NhbGl0eSBPbmVtAAAAB3VzZXJfaWRtAAAABU1hbHRlbgYAQpFEuZ4BYgAAASw.CTWz2zRd1qTFuGTbIV5Nn8ifBI3Sf6pvdwKbHWQWQ6s"
    }
    POST /locality/revoke-ticket

    Revoke a ticket.

    POST /locality/servicedoor

    Revoke a realm-user-key.

    Realm Access from User Machine
    POST /ticket/exchange-for-stamp

    Expects a ticket in the header. Expects user-id and password-hash as JSON. If encrypted_private_key and public_key are also in the JSON, will be treated as user registration. Will return public_key, encrypted_private_key and a realm-user-key. The token has one day lifetime.

    header
    {
    "Authorization": "LSFMyNTY.g2gDdAAAAAJtAAAACHJlYWxtX2lkbQAAAAxMb2NhbGl0eSBPbmVtAAAAB3VzZXJfaWRtAAAABU1hbHRlbgYAUUlLuZ4BYgAAASw.aHWc2hYA4LTvH2cCRgTOiDMaeFvh5VgLnaoqX2EGPvk"
    }
    registration payload
    {
    "user_id": "Malte",
    "password": "123",
    "public_key": "sfdgdsfgsdfggsfgsdfgsdfg",
    "encrypted_private_key": "123213"
    }
    answer · failure
    {
    "reason": "username_taken",
    "success": false
    }
    answer · registration success
    {
    "token": "SFMyNTY.g2gDdAAAAAJtAAAACHJlYWxtX2lkbQAAAAxMb2NhbGl0eSBPbmVtAAAAB3VzZXJfaWRtAAAAB01hbHRleHhuBgCa6ky5ngFiAAFRgA.EkxPUmkMmTH_SQjY0EO2nmsMoGURx4TPonVJWjMXGbo"
    }
    answer · login success
    {
    "encrypted_private_key": "123213",
    "public_key": "sfdgdsfgsdfggsfgsdfgsdfg",
    "token": "SFMyNTY.g2gDdAAAAAJtAAAACHJlYWxtX2lkbQAAAAxMb2NhbGl0eSBPbmVtAAAAB3VzZXJfaWRtAAAAB01hbHRleHhuBgDzEk65ngFiAAFRgA.bmwf1rKNEre1XSPihdFfvZstmLPKkuRQuENSQ56MiBQ"
    }
    POST /stamp/refresh

    Expects a realm-user-key in the header. Refresh a realm-user-key and invalidate the old token.

    GET /socket/websocket

    Expects a realm-user-key in the header.

    Channel API
    MethodParametersResponse
    broadcastevent, payload, timestamp, uuid, signatureservertime, sequence_id
    fetchsequence_idList of LocalityEvent (uuid, realm_id, event, channel, payload, servertime, sequence_id, timestamp)
    fetch_engramconfidenceengram (channel, content, publisher_count, last_consumed_sequence_id, hash), actual_confidence
    put_engramlast_consumed_sequence_id, content, signature

    Content is always E2E-encrypted. Signature is a cryptographic signature over the LocalityEvent (including timestamp).


    License

    Source-available, fairly priced.

    Locality Social Cloud is source-available under the Locality Social Cloud License (LSC-L) v1.0. A 30-day free evaluation is included. Licenses are available at locality.media/license.

    License TypePricing & Terms
    Consumer License €999 (Includes 3x Raspberry Pi nodes. Strictly for private, non-commercial use. No copying, no rehosting, no reselling).
    Startup License 7% equity in the company. Full commercial use for your own products. No sub-licensing, no commercial rehosting, and no redistribution as a competing managed cloud service.
    Enterprise License €1,000,000 / year. Production-ready tier for large-scale operations. No sub-licensing, no copying, and strictly prohibits deployment as a commercial managed service or infrastructure clone by third-party cloud providers.
    Permanent License €10,000,000 one-time payment. Perpetual rights for internal enterprise deployment. Source code access included. No copying, no commercial redistribution, and strict anti-competition clauses preventing any forms of managed cloud rehosting.

    Built On
    Contact

    Enterprise inquiries: legal@locality.media

    Manifesto

    There is no objective truth that humans can access or understand.

    What drives collective action is shared conviction, initiated by experience that gets multiplied in contexts of shared attention. Not all experience is equally convincing. Therefore convincing experience, scaled by shared attention, can drive collective action.

    Collective action can be directed at collective good or collective demise or stagnation. Stagnation is collective inaction and can only be achieved by gatekeeping shared attention.

    While North Korea is a contemporary stagnating civilization, bathed in ignorance, the era of the printing press between 1440 and 1930 created human rights, enlightenment thinking, the basis of our scientific understanding of the world, citizen's rights, parliaments and nation states.

    Today, we live in another captured century, initiated by the invention of the radio, solidified by the TV, finalized by Social Media. The internet and social media once promised freedom, but they were quickly captured by an oligopoly of technology companies who sold people's attention to corporate psychologists who get paid to create advertisement that fool people about their Telos — their goal and true purpose — in life.

    The price of this was the human heart. No longer does it aim at collective flourishing, act in service and liking of god, no longer does it know what life is about and why we are here.

    In these times, Locality Media was founded, based on one cognizance: as long as social networks are hard to make, as long as user-data is locked away and network-effects are real, a few dominant players will have control over a vast amount of human attention span, states will threaten to take away our means of expression, a damocles-sword of another dark age hangs above our all heads and our society stagnates.

    §

    Once upon a time, I wanted to address this problem by writing a social network. Existing social networks were good at serving everybody their own interest — losing not only connection with their physical neighbourhood, on top of that, losing the unifying signals of society, the causes everybody can get behind, the shared focal points of interest and attention that create common culture.

    My postulates were threefold:

  • (1)What gets viewed should only depend on Likes and each voice should be equal.
  • (2)The network should contain an encrypted private part.
  • (3)It is not a single app, but an ecosystem that seamlessly works together.
  • But the problems were larger. Writing a high-quality consumer app requires many iteration cycles of adapting to feedback. Having to write backend code and deploy each time significantly increases the time of a single iteration. Writing an encrypted aspect means we can not compute the state on the server. And only few people produce engaging content — and they go where the audience is. An empty network has neither creators nor audience.

    One day, a revelation. The KEY feature of SOCIAL Apps is that there is SHARED SPACE; it is DESIRED that everybody sees the SAME. SPACE ITSELF does it — like PHYSICAL SPACE. It perfectly synchronizes state between multiple observers, so it MUST be possible. Therefore it is not only possible to solve the synchronization problem — on top of that, it applies to EVERY abstraction of social behavior.

    If only I could solve this problem, I could publish it as a library, use VC to create a developer platform exposing it as a BaaS, and spawn a new ecosystem of social apps based on a shared protocol.

    The work on this was a long and lonely descent into a rabbit hole of cryptography, byzantine fault tolerance, lamport clocks and the very nature of general relativity and causality — and it was not always fun. But after two years of work, I have emerged with a solution.

    §

    Even today, the sovereignty of our shared information space is under attack. Algorithms serve each person a different reality and destroy the shared consensus of society. Advertisements and Public Relations institutions engineer false desires and manufacture shared delusions. Foreign subversion campaigns scaled by bots aim at western demoralization.

    Some of these treat our souls and minds like toys, others like tools. But they don't understand that we are Locality Social Cloud developers.

    Secret Agencies shout: No. We want to read your mind. We want to instill fear. We want mind control. But that is what the Catholic church preached, before Johannes Gutenberg invented the printing press and Martin Luther translated the bible.

    In 1536, William Tyndale was executed for heresy after translating the Bible into English; in 2012, Edward Snowden got labelled a traitor after revealing the biggest surveillance campaign in human history. Without the printing press, William Tyndale would have been a footnote in history.

    Politicians and corporations shout: No. We want to lead you against your own interest. We want to feast. And somebody must be feasted. But that is what King James II shouted, before the thought of John Locke cost his throne and led to the English Bill of Rights in 1689 — that is what the French Monarchy shouted, before the will of the people became self-aware and found its way.

    We are Locality Social Cloud developers.

    We are Aristotle, Guttenberg, Martin Luther, William Tyndale, John Locke.
    We are François-Marie Arouet, Abbé Sieyès, we are Benjamin Franklin, we are Thomas Paine.
    We are the will of western values and its people. Our thoughts tear down walls. Our minds set the chains ablaze.
    Our hearts do not faint at the signs of adversity. There is something in this world worth fighting for and we defend it.

    §

    And by god, the Western Spirit is by our side. Unexpected allies from the past and present times appear in our dire times. Mathematics itself, a 200-year-old theorem by the legendary 'Princeps Mathematicorum' Carl Friedrich Gauss, holds the key to a new world.

    Rewriting the problem of shared state synchronization in terms of replicated distributed automata allowed me to recognize it as yet another variant of the Gauss Divergence Theorem, a slight generalization: if and only if every measurable function on a manifold depends at most on shared background information, the flux through its boundary and inner variables, computation can be sharded. In a single dimension — only time — this allows us to cut the timeline at arbitrary points to compress the flux at the boundary between past and present into state snapshots called engrams.

    §

    But this story is not about me, but about us. Without you — without developers who dare put themselves in the lineage of high ancestors — this is dead code. I am nothing but the agent of the Western Spirit.

    §

    But armed and ready and with the strength of the Locality Social Cloud in our back, we can write the Digital Social Ecosystem of Tomorrows.

    And we calmly say no to the politicians, to the corporations, to the algorithms, to the secret agencies. Our soul will not be corrupted. Our will not broken. All your efforts are in vain.

    We are the Western Spirit become flesh, carried on as a tradition by the great men of our past. And as they won, so will we.

    §

    Let us together create a new world. Let us together fragment the social media ecosystem into thousands of apps with a shared userbase.

    If a sovereign digital collaboration tool can help your local community flourish — join the Social Cloud Developers. If you want to be part of the people who set things right, at least a little bit — join the Social Cloud Developers.

    If you look at history and you imagine yourself in the shoes of Voltaire, not King Louis XIV telling the people to eat cake — join the Social Cloud Developers. If you look at the present and you see fragmentation and insanity, join the Social Cloud Developers. If you look at the future and want to prevent dystopia and a ministry of truth, join the Social Cloud Developers.

    No system, no incentives, no amount of bureaucracy, military force, no vote, no war, no tax can fix a man aimed at the wrong things, can direct the world at what's beautiful, can keep a system free from corruption. The future of man is decided in his heart.

    Locality Media