Where Is The Exonomy?

Where Is The Exonomy.md

Where Is The Exonomy?

One of the more elusive concepts of the Exonomy is its location. How can we understand the essence of Exonomy's location when it operates absolutely without traditional servers and relies almost entirely on mobile phones, tables, and notebooks to locate its content and its operations? The following elaboration attempts to demystify both the topology and the mechanisms of the Exonomy

The Nature of Decentralization Based on IPFS

Each peer in our app manages a local IPFS node optimized for mobile devices, seamlessly integrating with Exonomy's decentralized architecture and communication. Locally generated data remains historically intact and is found using its content, not by an address that depends on its literal location, ensuring integrity and privacy. Nodes retrieve non-local data by querying peers via P2P pub-sub agreements, eliminating central server reliance, enhancing device independence, efficiency, and security while maintaining full decentralization.

• Each peer in the group runs a local js-ipfs instance of IPFS for lightweight mobile implementations. This local node operates directly on the device supporting the app’s decentralized architecture. Data is found based on a hash of its content, regardless of where it is physically located. This concept supports the intentionally decentralized philosophy of storage and retrieval enabling nodes to provide background support for each other with user regulated replication based redundancy.

• Data Storage: Each peer’s IPFS node manages the storage of all locally generated data, including user-specific content like chat messages, media files, and metadata. These objects are stored as content-addressable resources, ensuring immutability and efficient retrieval. User nodes and server-based nodes, alike, participate autonomously in background communications to ensure that all data eventually ends up where it belongs, not only based on who owns it but also depending on who needs to interact with it. Users establish criteria for themselves on their own through IPFS's pub-sub technology by simply expressing their interest in content and following (subscribing to) it. Unfollowing means ending a subscription and results in minimally delayed deletion of previously replicated but now undesirable data. This enhances Exonomy's efficiency is storage utilization and garbage collection.

• Data Retrieval: When a peer requests data, their local IPFS node first searches the local repository. If the requested content isn’t found locally, the node interacts with other peers in the P2P network to retrieve the data by broadcasting the search criteria. This ensures that all peers remain independent and self-sufficient in handling data demands. The ephemeral redundancy resulting from IPFS's background replication also significantly enhances content accessibility as well as the speed at which located content is retrieved. An example is a voucher promotional video that might be 100MB in size but is retrieved by a curious Exonomist from 100 nodes, each of which only needs, on average, to supply 1MB of that video. The responsiveness of each of those 100 nodes depends obviously on the upload bandwidth available to the device hosting it, but such bandwidth constraints are efficiently mitigated by spreading the requesting node's dependence across all 100 nodes.

• Network Communication: IPFS enables direct P2P communication using its pub-sub system for real-time data sharing and discovery. The pub-sub system allows peers to subscribe to and publish events or content, ensuring that updates are distributed to all interested parties efficiently. This mechanism underpins Exonomy’s decentralized operations, where users can follow vouchers, discussions, or content updates. IPFS discovery protocols ensure that peers dynamically locate and maintain connections to others in the network, adapting to changes in peer availability. By decentralizing communication, Exonomy enhances resilience against outages, ensures privacy by avoiding centralized tracking, and reduces latency by enabling local peer interactions where possible. In addition, the lack of centralized bottlenecks allows for seamless scalability, as every node contributes to the overall network capacity. This design also supports offline-first functionality, enabling users to interact with local data and seamlessly synchronize updates when connectivity is restored, always respecting topological proximity.

• In our app, this decentralized structure ensures:

  • Independence of each device: Every peer operates autonomously, maintaining full functionality without relying on centralized servers. This removes single points of failure, ensuring uninterrupted operation even if certain peers are temporarily unreachable.
  • Localized data management: Data is stored and processed directly on devices, minimizing network overhead and enhancing the responsiveness of interactions. The architecture leverages IPFS’s capability to prioritize nearby peers for faster communication and content retrieval.
  • Complete privacy and security: All interactions occur directly between peers, with no intermediaries storing or processing data. Content is cryptographically hashed, providing tamper-proof storage and ensuring that only users with the appropriate keys or permissions can access the data.

This approach ensures Exonomy remains robust, efficient, and aligned with its mission to deliver a fully decentralized, user-centric application.

How Do Peers Interact with Decentralized Content?

In our decentralized application, each peer uses IPFS and OrbitDB to interact with content efficiently and securely. When a peer creates new data, such as a message, it is stored locally in their IPFS node as a content-addressable object. This ensures the data is immutable and can be uniquely identified by its hash. The hash is then broadcast to the network using IPFS’s pub-sub system, notifying all peers subscribed to the relevant OrbitDB database. This notification contains only the hash, not the actual content, preserving bandwidth and ensuring privacy.

Upon receiving the hash, other peers query their local IPFS nodes first to check if the data is already cached. If the data isn’t available locally, the node broadcasts a request to the network, asking peers with the required content to respond. The system dynamically resolves these requests, enabling efficient retrieval while maintaining decentralization. Once retrieved, the data is stored locally by each peer, increasing redundancy and ensuring future requests are resolved faster. This decentralized replication enhances resilience, ensuring content availability even in the absence of specific peers.

How Do Peers Interact with Each Other?

IPFS ensures seamless P2P communication and data distribution by leveraging the strengths of its pub-sub and DHT systems. Peers dynamically discover each other in local networks through mDNS (Multicast DNS), which broadcasts service advertisements to nearby devices using multicast packets. This allows devices on the same network to quickly identify and connect without requiring centralized infrastructure. In broader networks, IPFS leverages a Distributed Hash Table (DHT) for discovery. Peers store and retrieve information about other nodes in the DHT, enabling efficient lookups of content providers across the network. These mechanisms ensure decentralized, scalable, and resilient peer discovery regardless of the network’s size or topology. To further optimize performance, bootstrap nodes can anchor the network and maintain persistent connectivity, while pinning services can ensure critical data remains permanently available. These mechanisms ensure that peers can interact with content efficiently, even when offline peers temporarily limit access.

In practical terms, this architecture supports scalable data exchange by encouraging redundancy and reducing latency. For example, when a user retrieves a large file or message, IPFS can aggregate smaller chunks from multiple peers simultaneously, optimizing bandwidth usage. Furthermore, efficient local caching and preloading mechanisms reduce the need for repeated network lookups, enhancing the overall user experience. Together, these features create a robust and autonomous network where peers can interact with decentralized content seamlessly and efficiently.