Restructure all the docs in two main folders: Core and App

.gitignore

@@ -0,0 +1 @@
+.DS_Store

Concepts/1.Web of Trust.md

@@ -1,5 +1,3 @@
-# Web of Trust
-
 The "Web of Trust" is a decentralized trust model used in cryptography, particularly in systems like _PGP_, _GnuPG_, and other _OpenPGP_ compatible systems, to establish the authenticity of the binding between a public key and its owner.
 
 This model is an alternative to the centralized trust model of a __Public Key Infrastructure (PKI)__, which relies on a __certificate authority (CA)__ or a hierarchy of such authorities.

Concepts/2.Censorship.md

@@ -1,5 +1,3 @@
-# Censorship
-
 Censorship in the digital age is a complex and multifaceted issue, affecting how information is shared, accessed, and controlled. It's not just about blocking content; it's about the power dynamics at play, the implications for freedom of expression, and the challenges of maintaining privacy and security in an increasingly interconnected world.
 
 ## Understanding Censorship

Concepts/3.Credible Exit.md

@@ -1,5 +1,3 @@
-# Credible exit
-
 It is a concept that emphasizes the ability for users to leave a platform or service without being locked in, maintaining control over their data and experiences. This concept is gaining traction as a way to ensure user autonomy and foster competition among service providers.
 
 This [substack post](https://subconscious.substack.com/p/credible-exit) by Gordon Brander is a good read as introduction to the topic. The following is a summary:

Documents.md

@@ -0,0 +1,21 @@
+> **The current Knowledge base is a mix of reality, dreams, visions, actuality and plans.**
+
+When accessing the documentation on GitHub, please be aware that the content may not be fully represented. To ensure a comprehensive understanding of the _Pubky Knowledge Base_, we recommend importing the data into __Obsidian__ or __Quartz__ site. This will enable you to access the complete range of information and features available in the repository.
+
+The following blocks provide step-by-step guidance on how to import the _Pubky Knowledge Base_.
+## Obsidian
+
+The root directory is an [Obsidian Vault](https://help.obsidian.md/Getting+started/Create+a+vault#Open+existing+folder).
+1. Download [Obsidian](https://obsidian.md/) app
+2. Add a new vault selecting the folder path
+
+![[images/obsidian.png]]
+## Build static Quartz site
+
+For those who prefer to render the documentation directly in their browser, a preliminary step is required. To facilitate this, please ensure that [NodeJS](https://nodejs.org/en/download/prebuilt-installer) is installed on your system
+
+1. Enter in the terminal to the project root and access to the `/quartz` directory (`cd quartz`)
+2. Install dependencies with `npm install`
+3. Finally build the site with `npm run docs` and check it out at [localhost:8080](http://localhost:8080/)
+
+![[images/quartz.png]]

ELI5.md

@@ -1,7 +1,7 @@
 ## ELI5: Pubky Explained for Children
 
-Like a kite, [data](1.Data%20Stores.md) is in the cloud, but you hold its string.
+Like a kite, [data](Data%20Stores.md) is in the cloud, but you hold its string.
 
-Your friends can find your messages by finding your kite in the sky ([[Pkarr/index]] in the [[DHT]]) and following the string down to the message board you are currently posting on.
+Your friends can find your messages by finding your kite in the sky ([[0.Introduction]] in the [[DHT]]) and following the string down to the message board you are currently posting on.
 
-You can move your kite (your [data](1.Data%20Stores.md)) anywhere and your friends will still be able to find it as long as you are holding the string of the kite ([[Pkarr/index]] private key).
+You can move your kite (your [data](Data%20Stores.md)) anywhere and your friends will still be able to find it as long as you are holding the string of the kite ([[0.Introduction]] private key).

Pkarr/2.Getting Started with Pkarr.md

@@ -1,21 +0,0 @@
-This guide will help you understand how to publish and resolve resource records using [[Pkarr/index]].
-
-## Publishing Resource Records
-
-To publish resource records for your key, you need to sign a small encoded [[DNS]] packet (<= 1000 bytes) and publish it on the DHT. This can be done through a relay if necessary.
-
-## Resolving Resource Records
-
-To resolve some key's resources, applications can query the [[DHT]] directly or through a relay. They will then verify the signature themselves.
-
-## [[DNS]] Queries Over [[HTTPS]]
-
-Existing applications unaware of [[Pkarr/index]] can make normal [[DNS]] Queries over [[HTTPS]] ([[DoH]]) to [[Pkarr/index]] servers.
-
-## Caching and Scalability
-
-Clients and [[Pkarr/index]] servers cache records extensively to minimize [[DHT]] traffic and improve scalability. The [[DHT]] drops records after a few hours, so it's important to republish records periodically.
-
-## Next Steps
-
-For more technical details on [[Pkarr/index]]'s architecture and how it works, refer to the [[4.Architecture]] note.

Pkarr/3.Expectations.md

@@ -1,21 +0,0 @@
-Understanding the expectations and limitations of [[Pkarr/index]] is crucial for effective use. This note outlines what [[Pkarr/index]] is not and what users should expect.
-
-## Not a Storage Platform
-
-[[Pkarr/index]] is not a storage platform. Records are ephemeral and need to be refreshed regularly to remain on the DHT.
-
-## Not a Real-time Communication Medium
-
-[[Pkarr/index]] is not designed for real-time communication. It is optimized for infrequent updates and heavy caching to reduce traffic.
-
-## Rate Limiting and Proof of Work
-
-Expectations include enforcing harsh rate-limiting and possibly demanding proof of work for updates.
-
-## Caching and Propagation Time
-
-Records are heavily cached, and updates might take some time to propagate. In case of a cache miss, querying the [[DHT]] might take a few seconds.
-
-## Next Steps
-
-For a deeper understanding of why [[Pkarr/index]] was created and its motivation, refer to the [[1.Why Pkarr?]] note.

PubKy App/App.md

@@ -1,14 +0,0 @@
-# Pubky App
-
-Pubky App will be available as both a desktop application and a hosted website service (standard website) that allows users to interface with the social media layer of Pubky using Synonym hosted services. Synonym will be initially hosting: [[1.Data Stores |Data stores]], [[2.Aggregators|aggregators]], [[Feeds|feeds]], [[Pubky Core/Search|search]] and Application Backends.
-
-- Users are able to take control of the data and exit the Synonym hosted services and run their own without hampering discoverability ([[3.Credible Exit|credible exit]]).
-
-- Aggregators and Application Backends use cryptographically signed data and reformat and render data within multiple familiar formats like social media, photo feeds, forums etc. All from the same source data, with verifiable sources. Users can run Pubky locally, or rely on our servers for trust-minimized hosting and rendering.
-
-- Pubky App uses the open Pubky Core for nearly all features, allowing users to avoid censorship by choosing self-hosting or alternate hosts without losing followers or integrity. 
-
-- Pubky also features support for Paykit, our open payment protocol for coordinating payments among peers supporting various methods. This allows users to create sub-accounts from master wallets for familiar payment experiences. This suite of features removes any requirement from Synonym to custody user funds, while allowing for users to set up subscriptions, recurring payments, paywalls, etc, in a P2P way. 
-
-- This feature will not be in the first launch version of Pubky app, but it is worth noting that next year we will enable all users to buy and sell data in this way.
-

PubKy App/Backend/Aggregator.md

@@ -0,0 +1,16 @@
+## Pubky Aggregators
+
+Aggregators are specialized reducers or gatekeepers that continuously scan and collect data from various sources, such as [[Data Stores|data stores]]. They decide what data to allow in and what to keep out.
+
+When the aggregator receive new events, it evaluates it against its predefined criteria. If the data meets the criteria, the aggregator allows it to pass through, making it available for further processing or storage. However, if the data doesn't meet the criteria, the aggregator blocks it, preventing it from entering the system.
+
+By controlling the flow of information, aggregators play a crucial role in maintaining data quality, preventing information overload, and ensuring that only the most valuable and relevant data is used.
+
+### Characteristics
+
+- **Fine-grained access controls**: Users and aggregators have granular control over what data is shared, with whom, and under what conditions, ensuring selective and secure data exchange.
+- **Efficient data synchronization**: Merkle trees enable fast and efficient synchronization of incremental changes from data stores, reducing the overhead of data aggregation.
+- **Normalized data schemas**: Standardized data schemas facilitate interoperability between services, making it easier to integrate and exchange data across the network.
+- **Public and niche aggregators**: The network supports both large-scale, public aggregators for discoverability and smaller, niche aggregators that cater to specific communities or use cases.
+- **Core user graph expansion**: The aggregation process starts with a core user graph and expands outward through connections, enabling the network to grow organically and efficiently.
+- [[2.Censorship|Censorship resistance]]: The system's censorship resistance is achieved through a decentralized aggregation architecture, where data aggregation is distributed across a network of **independent, autonomous aggregators**. This design ensures that no single entity or node has control over the aggregation process, making it more resilient to censorship attempts.

PubKy App/Backend/Indexer.md

@@ -0,0 +1,10 @@
+The Indexer is a specialized component that plays a crucial role in the system by normalizing and transforming the aggregated data from multiple [[Data Stores|data stores]] into a unified view. This enables cross-data store search, queries, and discovery, allowing users to access and analyze data from various sources in a seamless and efficient manner.
+
+### Characteristics
+
+1. **Data Normalization**: The Indexer normalizes the data from multiple sources, handling differences in format, structure, and schema. This involves transforming the data into a consistent format, resolving data conflicts, and ensuring that the data is accurate and reliable.
+2. **Data Transformation**: The Indexer transforms the normalized data into a unified view, making it possible to query and analyze the data across multiple [[Data Stores|data stores]]. This unified view enables users to access data from different sources as if it were a single, cohesive dataset.
+3. **Data Integrity**: The Indexer ensures data integrity through secure synchronization protocols, guaranteeing that the indexed data is consistent and up-to-date. This involves implementing measures to prevent data corruption, ensuring that data updates are propagated across all data stores, and maintaining a high level of data quality and accuracy.
+4. **Scalability**: The Indexer is designed to handle large volumes of data from multiple sources, ensuring that it can scale to meet the needs of a growing user base and increasing data demands.
+
+By normalizing, transforming, and ensuring the integrity of the data, the Indexer provides a robust and scalable solution for cross-data store search, queries, and discovery

PubKy App/Backend/Introduction.md

@@ -0,0 +1,11 @@
+The Backend is responsible for collecting ([[Aggregator|aggregators]]) and organizing ([[Indexer|indexer]]) data from various sources, known as [[Data Stores|data stores]].
+
+![[images/pubky-backend.png]]
+
+Imagine you're trying to find a specific document in a large library. The backend is like a librarian who searches through the shelves, finds the right documents, and prepares them for you to use. This ensures that the data is accurate, up-to-date, and in a format that's easy to work with.
+
+### Main components
+
+- [[Aggregator|Aggregators]] execute a **data retrieval protocol** to obtain data from **data storage**, initiating a process that retrieves and collects data from various sources.
+- [[Indexer|Indexers]] receive aggregated data from the **Aggregators** and initiate a rigorous **data normalization** process, transforming and converting the data into a standardized format to ensure consistency and accuracy.
+- [[Web Server|Web servers]] provide the requested data to [[PubKy App/Client/Introduction|Pubky client]]

PubKy App/Backend/Web Server.md

@@ -0,0 +1,17 @@
+The system comprises a suite of **backend services** that orchestrate the integration of **data feeds**, **search functionality**, and **user interface configurations**. The system provides a unified platform for data ingestion, processing, and presentation, enabling seamless interactions between the frontend and backend components. 
+
+### Services
+
+- __Feeds__ - Curated views of aggregated data presented to users. Can include timelines, [[Tags|tags]], [[Profiles|profiles]], etc.
+- __Search__ - Services that index aggregated data and enable full text/attribute searches.
+- __Identity__ - It provides single sign-on through self-sovereign credentials. 
+- [Payments](Paykit.md) - It handles microtransactions like tipping within a peer-to-peer economy.
+
+### Architecture
+
+The web server can be designed and implemented using various architectural patterns, depending on the specific requirements of the data request workflow. Two prominent architectural styles that can be employed are:
+
+- **Monolithic Architecture**: A **single-tiered architecture** where the web server is constructed as a self-contained unit, encompassing all necessary components and functionality. This approach is characterized by a **tightly-coupled** design, where all components are integrated into a single executable or deployable unit.
+- **Microservices Architecture**: A **multi-tiered architecture** where the web server is decomposed into a collection of **loosely-coupled**, independent services that communicate with each other using **APIs** and **messaging protocols**. Each microservice is responsible for a specific **business capability** or **data domain**, enabling greater flexibility, scalability, and resilience.
+
+The choice of architecture depends on various factors, including **data request patterns**, **traffic volume**, **performance requirements**, **development team expertise**, and **maintenance considerations**.

PubKy App/Client/Features/Layouts.md

@@ -0,0 +1,3 @@
+# Layouts
+
+Pubky client offers multiple customizable UI layouts for users that prefer different _column_, _grid_, and _list_ layouts for their feeds.

PubKy App/Client/Features/Notifications.md

@@ -1,6 +1,6 @@
 # Notifications
 
-Pubky App tracks various event or activities the user may be interested in, and provides relevant notifications for interactions and other relevant activity to the user. Notifications are a way to keep you informed about what's happening in the app, even when you're not actively browsing your timeline.
+Pubky client tracks various event or activities the user may be interested in, and provides relevant notifications for interactions and other relevant activity to the user. Notifications are a way to keep you informed about what's happening in the app, even when you're not actively browsing your timeline.
 
 Here are some common types of notifications you might receive:
 

PubKy App/Client/Features/Posts.md

@@ -1,6 +1,6 @@
 # Posts
 
-In Pubkey App, a **post** is a message that a user publishes on the platform. Posts are the core content and they can contain a variety of information, including:
+In Pubkey client, a **post** is a message that a user publishes on the platform. Posts are the core content and they can contain a variety of information, including:
 
 1. **Text**: There is not text limitation of plain text, which can include words, phrases, sentences, or even just a single character.
 2. **Media**: Post can include various types of media, such as images and videos.

PubKy App/Client/Features/Profiles.md

@@ -1,6 +1,6 @@
 # Profiles
 
-In Pubky, a **profile** refers to a user's personal page on the app, which displays their information, posts, and other content. A Pubky profile is a unique identity that represents a public-key.
+In Pubky client, a **profile** refers to a user's personal page on the app, which displays their information, posts, and other content. A Pubky profile is a unique identity that represents a public-key.
 
 Here are some key components of a Pubky profile:
 

PubKy App/Client/Features/Tags.md

@@ -5,6 +5,6 @@ They are keywords or phrases that are added to a tweet to help users find and en
 **How do tags work?**
 
 1. **Hashtags**: Tags are denoted by the "#" symbol, followed by a word or phrase. For example, #Pubky, #privacy, or #segwit.
-2. **Clickability**: When you click on a tag, Pubky takes you to a page that displays all the posts that have used that same tag.
+2. **Clickability**: When you click on a tag, Pubky client takes you to a page that displays all the posts that have used that same tag.
 3. **Discovery**: Tags help users discover new content, accounts, and conversations related to a specific topic.
 4. **Categorization**: Tags help categorize posts, making it easier for users to find and engage with content that interests them.

PubKy App/Client/Features/Trends.md

@@ -0,0 +1,3 @@
+# Trends
+
+Pubky client can provide statistical views of the data it has access to and then establish visualizations and leaderboard lists of trending posts, tags, and users.

PubKy App/Client/Introduction.md

@@ -0,0 +1,16 @@
+# Pubky Client
+
+![[pubky-header.png]]
+
+The Pubky client will be available as both a desktop application and a hosted website service (standard website) that allows users to interface with the social media layer of [[PubKy App/Backend/Introduction|Pubky Backend]] using [Synonym](https://synonym.to/) hosted services.
+
+Using the library analogy again, the Pubky Client is like a personalized research assistant who takes the prepared documents from the librarian ([[PubKy App/Backend/Introduction|backend]]) and creates a customized report just for you. This report is designed to be easy to read and understand, with all the relevant information presented in a clear and concise manner.
+
+- Users are able to take control of the data and exit the Synonym hosted services and run their own without hampering discoverability ([[3.Credible Exit|credible exit]]).
+
+- Pubky client uses the open [[Pubky Core/Introduction|Pubky Core]] for nearly all features, allowing users to avoid censorship by choosing self-hosting or alternate hosts without losing followers or integrity. 
+
+- Pubky also features support for [[Paykit|paykit]], our open payment protocol for coordinating payments among peers supporting various methods. This allows users to create sub-accounts from master wallets for familiar payment experiences. This suite of features removes any requirement from [Synonym](https://synonym.to/) to custody user funds, while allowing for users to set up subscriptions, recurring payments, paywalls, etc, in a P2P way. This feature will not be in the first launch version of Pubky app, but it is worth noting that next year we will enable all users to buy and sell data in this way.
+
+- Communities facilitate moderation and discovery around shared interests.
+

PubKy App/Introduction.md

@@ -0,0 +1,36 @@
+![[pubky-app.png]]
+
+> Synonym will be initially hosting: [[Data Stores|Data stores]] and [[PubKy App/Introduction|Pubky App]]
+
+## Overview
+
+Pubky-app's initial focus is building a decentralized social media protocol.
+
+## Key aspects
+
+- **Data Ownership**: Users have full autonomy over their data, hosting it on **independent [[Data Stores|data stores]]** that are decentralized and distributed across the network. This approach enables users to maintain **control** and **ownership** of their data, while also ensuring **data sovereignty** and **privacy**. 
+- **Profiles**: The system employs a **decentralized data storage** approach, where **post**, **comment**, and **like** data are stored in association with **user profiles**.
+- [[2.Aggregators|Aggregators]] collecting social graphs
+- [[Feeds]] of followings' activities
+- [[Pubky Core/Search|Searching]] profiles and posts
+- Notification delivery through [[PubKy App/Backend/Introduction|aplication backends]] 
+- Distributed moderation through user blocking
+
+## Components
+
+The Pubky App is a complex system that can be broken down into two main components: the [[PubKy App/Backend/Introduction|backend]] and the [[PubKy App/Client/Introduction|client]]. These two pieces work together to provide a seamless user experience.
+
+##### Backend: The Data Organizer
+
+It collects and organizes data from various sources, processing it into a usable format.
+
+##### Client: The User Interface
+
+It is the part of the Pubky App that you interact with directly. It's responsible for taking the organized data from the Backend and presenting it to you in a visually appealing and easy-to-understand way.
+
+## MVP Architecture
+
+The early versions of Pubky app take some shortcuts over the [[Pubky Core/Introduction|Pubky Core]] design. The MVP app is centralized, therefore we saved time and complexity by aggregating functionality into fewer components. The main two components are the `Homeserver` and the `Indexer`
+
+- The `Homeserver` fulfils the function of [[Data Stores|data stores]], [[0.Introduction|Pkarr]] republishing for users, identity-provider (Oauth-like sign-in). Users maintain a trust relationship with the `Homeserver`.
+- The `Indexer` fulfils the function of the [[PubKy App/Backend/Introduction|backend]] for the Pubky App. 

PubKy App/Layouts.md

@@ -1,3 +0,0 @@
-# Layouts
-
-Pubky app offers multiple customizable UI layouts for users that prefer different _column_, _grid_, and _list_ layouts for their feeds.

PubKy App/Trends.md

@@ -1,3 +0,0 @@
-# Trends
-
-Pubky App can provide statistical views of the data it has access to and then establish visualizations and leaderboard lists of trending posts, tags, and users.

Pubky App.md

@@ -1,28 +0,0 @@
-## Pubky.app Social Media
-
-Pubky-app's initial focus is building a decentralized social media protocol. Key aspects include:
-
-- User profiles hosted on [[1.Data Stores|data stores]]
-
-- Post/comment/like data stored with profiles
-
-- [[2.Aggregators|Aggregators]] collecting social graphs
-
-- [[Feeds]] of followings' activities
-
-- [[Pubky Core/Search|Searching]] profiles and posts
-
-- Notification delivery through [[3.Applications|application]] Backends
-
-- Distributed moderation through [user blocking](1.Web%20of%20Trust.md)
-
-The goal is to recreate core social features without dependence on any centralized company or platform.
-
-# Pubky App MVP Architecture
-
-The early versions of Pubky app take some shortcuts over the Pubky Core design. The MVP app is centralized, therefore we saved time and complexity by aggregating functionality into fewer components. The main two components are the `Homeserver` and the `Indexer`
-
-- The `Homeserver` fulfils the function of: [[1.Data Stores|data stores]], [[Pkarr/index|Pkarr]] republishing for users, identity-provider (Oauth-like sign-in). Users maintain a trust relationship with the `Homeserver`.
-- The `Indexer` fulfils the function of the [Application Backend](3.Applications.md) for the Pubky App. 
-
-Given that all of the [[1.Data Stores|data stores]] related to Pubky App are centralized in the `Homeserver`, there is no need for an [[2.Aggregators|aggregator]] (i.e., web crawler for Data Stores) in the early versions of the social Pubky app.

Pubky Core/0.index.md

@@ -1,19 +0,0 @@
-## Pubky Core Overview
-
-![[pubky_core_arch.png]]
-
-Pubky is built on a few core concepts:
-
-- **[[1.Data Stores|Data Stores]]** - Decentralized data storage nodes that host user data. Data is encrypted at rest.
-
-- **[[2.Aggregators|Aggregators]]** - Services that collect and aggregate data from multiple [[1.Data Stores|data stores]] into a single normalized view.
-
-- **[[Feeds]]** - Curated views of aggregated data presented to users. Can include timelines, hashtags, profiles, etc.
-
-- **[[Pubky Core/Search|Search]]** - Services that index aggregated data and enable full text/attribute searches.
-
-- **[Application Backends](3.Applications.md)** - Backend services that integrate feeds, search, and user interfaces/configurations.
-
-- **[[Pkarr/index|Pkarr]]** - Self-issued public keys that function as sovereign, publicly addressable domains are used to resolve the previous components.
-
-Pubky's distributed architecture aims to provide user autonomy through [[3.Credible Exit|credible exit]] between interchangeable components.

Pubky Core/1.Data Stores.md

@@ -1,19 +0,0 @@
-## Pubky Data Stores
-
-Data Stores are decentralized storage nodes that host user data in an encrypted format. Key aspects include:
-
-- Data is encrypted at rest using users' public keys. Only the user has access.
-
-- The user also has the option to publish public data and be accessible for everyone
-
-- Stores provide access to data through an API or via Pub/Sub, allowing reads by authorized services.
-
-- Versioning and conflict resolution is handled through Merkle trees for efficient syncing.
-
-- Stores can be run by individuals, co-ops, or commercial providers anonymously.
-
-- Redundancy is achieved through data replication across multiple data stores.
-
-- [[2.Incentives|Incentives]] encourage availability through services fees or peer-to-peer micropayments.
-
-- Data control remains with users even if a store goes offline through [[3.Credible Exit|credible exit]] options.

Pubky Core/2.Aggregators.md

@@ -1,17 +0,0 @@
-## Pubky Aggregators
-
-Aggregators collect and normalize social data from multiple [[1.Data Stores|data stores]]:
-
-- Initial aggregation starts from a core user graph and expands outward through connections.
-
-- Fine-grained access controls allow selective data sharing between users and aggregators.
-
-- Merkle trees enable efficient synchronization of incremental changes from [[1.Data Stores|stores]].
-
-- Normalized data schemas support interoperability between services.
-
-- Public aggregators operate at scale for discoverability, while smaller niche aggregates also exist.
-
-- [[2.Censorship|Censorship resistance]] comes from distributing aggregation across independent operators.
-
-- Microservices enable modular aggregation of different data types (profiles, posts, comments, etc).

Pubky Core/3.Applications.md

@@ -1,17 +0,0 @@
-## Pubky Applications
-
-Apps build specialized frontends tailored for specific workflows or platforms.
-
-Application Backends power features by integrating aggregated data:
-
-- [[Feeds]] curate timelines, hashtags, profiles and notify users.
-
-- [[Pubky Core/Search|Search]] indexes enable full-text/attribute queries across user profiles and content.
-
-- Communities facilitate moderation and discovery around shared interests.
-
-- [Payments](Paykit.md) handle microtransactions like tipping within a peer-to-peer economy.
-
-- Identity services provide single sign-on through self-sovereign credentials.
-
-By decoupling features from centralized control, independent development remains open and vibrant.

Pubky Core/Data Stores.md

@@ -0,0 +1,24 @@
+The network is composed of multiple, independent data stores, which provides censorship resistance and ensures that no single entity controls the flow of information. 
+
+### Data Storage and Access
+
+- **Client-side encryption**: Data at rest is encrypted using users' public keys, ensuring that only the data owner possesses the decryption key and has exclusive access to the encrypted data.
+- **Optional data publication**: Users have the option to publish data publicly, making it accessible to all, or maintain control over access through fine-grained permissions.
+
+### Data Retrieval and Synchronization
+
+- **API and Pub/Sub access**: Authorized services can access data through a RESTful API or via a publish-subscribe (Pub/Sub) messaging system, enabling efficient and scalable data retrieval.
+- **Merkle tree-based versioning**: The system employs Merkle trees to manage versioning and conflict resolution, ensuring efficient data synchronization and minimizing data inconsistencies.
+
+### Decentralized Storage Architecture
+
+- **Federated data stores**: Data stores can be operated by individuals, cooperatives, or commercial entities, with the option for anonymous operation, promoting a decentralized and resilient storage ecosystem.
+- **Redundancy through replication**: Data is replicated across multiple data stores to ensure high availability and redundancy, minimizing the risk of data loss or unavailability.
+
+### Incentivizing Data Availability
+
+- **Incentive mechanisms**: The system incorporates [[2.Incentives|incentives]], such as service fees or peer-to-peer micropayments, to encourage data availability and storage providers to maintain high uptime and data accessibility.
+
+### User Data Control and Credible Exit
+
+- **User-centric data control**: Users retain control over their data even in the event of a data store outage or termination, thanks to credible exit options that ensure data portability and availability.

Pubky Core/Introduction.md

@@ -0,0 +1,21 @@
+## Pubky Core Overview
+
+![[pubky-core.png]]
+
+Pubky Core is built on a few core concepts:
+
+- **[[Data Stores|Data Stores]]** - Decentralized data storage nodes that host user data. Data is encrypted at rest.
+
+- **[[0.Introduction|Pkarr]]** - Self-issued public keys that function as sovereign, publicly addressable domains are used to resolve the previous components.
+
+Pubky Core's distributed architecture aims to provide user autonomy through [[3.Credible Exit|credible exit]] between interchangeable components.
+
+## Target Users
+
+Pubky Core is made for developers and builders of internet software products. We will actively work to cultivate a community of builders and startups using our tech.
+
+[[PubKy App/Introduction|Pubky App]] is made for anyone interested in social media and online publishing that wants new ways to control their data and more control over which posts they see.
+
+## Why? What is the reward?
+
+The reward for everyone is a more open, privacy-focused, usable, modular and secure web. The reward for [Synonym](https://synonym.to/) is to be positioned to disrupt Big Tech as an industry, gaining user recognition and reputation through the effort of building a decentralized ecosystem. The ultimate potential is for [Synonym](https://synonym.to/) to become a major player in online publishing & social media, while also monetizing in ways similar to Google, as well as opportunities to introduce new users to our ecosystem of products and services.

Pubky Core/Pkarr/0.Introduction.md

@@ -19,7 +19,7 @@ The core idea is to streamline the process of publishing and resolving resource
 3. **Fallback for Existing Applications**: Applications unaware of Pkarr can make normal [[DNS]] Queries over [[HTTPS]] (DoH) to Pkarr servers, ensuring accessibility.
 4. **Caching and Republishing**: Both clients and Pkarr servers cache records extensively to improve scalability. The [[DHT]] drops records after a few hours, necessitating periodic republishing to keep records alive.
 
-For more technical details on Pkarr's architecture and how it works, refer to the [[4.Architecture]] note.
+For more technical details on Pkarr's architecture and how it works, refer to the [[4.Architecture|architecture]] note.
 
 ## Getting Started
 

Pubky Core/Pkarr/2.Getting Started with Pkarr.md

@@ -0,0 +1,21 @@
+This guide will help you understand how to publish and resolve resource records using [[0.Introduction|pkarr]].
+
+## Publishing Resource Records
+
+To publish resource records for your key, you need to sign a small encoded [[DNS]] packet (<= 1000 bytes) and publish it on the DHT. This can be done through a relay if necessary.
+
+## Resolving Resource Records
+
+To resolve some key's resources, applications can query the [[DHT]] directly or through a relay. They will then verify the signature themselves.
+
+## [[DNS]] Queries Over [[HTTPS]]
+
+Existing applications unaware of [[0.Introduction|pkarr]] can make normal [[DNS]] Queries over [[HTTPS]] ([[DoH]]) to [[0.Introduction|pkarr]] servers.
+
+## Caching and Scalability
+
+Clients and [[0.Introduction|pkarr]] servers cache records extensively to minimize [[DHT]] traffic and improve scalability. The [[DHT]] drops records after a few hours, so it's important to republish records periodically.
+
+## Next Steps
+
+For more technical details on [[0.Introduction|pkarr]]'s architecture and how it works, refer to the [[4.Architecture|architecture]] note.

Pubky Core/Pkarr/3.Expectations.md

@@ -0,0 +1,21 @@
+Understanding the expectations and limitations of [[0.Introduction|pkarr]] is crucial for effective use. This note outlines what [[0.Introduction|pkarr]] is not and what users should expect.
+
+## Not a Storage Platform
+
+[[0.Introduction|pkarr]] is not a storage platform. Records are ephemeral and need to be refreshed regularly to remain on the DHT.
+
+## Not a Real-time Communication Medium
+
+[[0.Introduction|pkarr]] is not designed for real-time communication. It is optimized for infrequent updates and heavy caching to reduce traffic.
+
+## Rate Limiting and Proof of Work
+
+Expectations include enforcing harsh rate-limiting and possibly demanding proof of work for updates.
+
+## Caching and Propagation Time
+
+Records are heavily cached, and updates might take some time to propagate. In case of a cache miss, querying the [[DHT]] might take a few seconds.
+
+## Next Steps
+
+For a deeper understanding of why [[0.Introduction|pkarr]] was created and its motivation, refer to the [[1.Why Pkarr?|why pkarr?]] note.

Pubky Core/Pkarr/4.Architecture.md

@@ -1,5 +1,4 @@
-In-depth look at the architecture of [[Pkarr/index]], including its components and how they interact.
-
+In-depth look at the architecture of [[0.Introduction|pkarr]], including its components and how they interact.
 ## Components
 
 - **Client**: Applications or users that publish or query resource records.

Pubky Core/Search.md

@@ -1 +0,0 @@
-TODO

Readme.md

@@ -1,11 +0,0 @@
-# Pubky Knowledge Base as Obsidian+Quartz site
-
-## Add Knowledge
-
-The root directory is an Obsidian Vault. Just add Pubky knowledge to it!
-
-The current Knowledge base is a mix of reality, dreams, visions, actuality and plans.
-
-## Build static Quartz site
-
-Go into the `/quartz` dir `cd quartz`. Install deps with `npm install` then build the site with `npm run docs`. Check it out at [localhost:8080](http://localhost:8080/)

TLDR.md

@@ -1,10 +1,8 @@
-## TLDR; [pubky.app](Pubky%20App.md) in Brief
+[[PubKy App/Introduction|Pubky App]] is a decentralized alternative to social media platforms like Twitter. It uses a distributed architecture where:
 
-[pubky.app](Pubky%20App.md) is a decentralized alternative to social media platforms like Twitter. It uses a distributed architecture where:
-
-- Users host their own data on independent [[1.Data Stores|data stores]]
-- Services [aggregate](2.Aggregators.md) data across stores into a unified view
-- [[Feeds]] and [[PubKy App/Search|search]]search present curated views of the aggregated data
-- [Application](3.Applications.md) back-ends integrate features without centralized control
+- Users host their own data on independent [[Data Stores|data stores]]
+- Services [aggregate](Aggregator.md) data across stores into a unified view
+- Feeds and search present curated views of the aggregated data
+- [Application](Applications.md) back-ends integrate features without centralized control
 
 The end goal is to give individuals self-sovereign digital identity and true ownership over social profiles/activity without fear of data misuse or account bans by any single entity.

Technologies/DoH.md

@@ -1,6 +1,6 @@
 # DNS over HTTPS - DoH
 
-It is a security protocol that encrypts [[DNS]] queries and responses, enhancing privacy and security by preventing eavesdropping and tampering. In the context of [[Pkarr/index|pkarr]], DoH plays a crucial role in ensuring that [[DNS]] queries made to resolve public-key addresses are secure and cannot be intercepted or manipulated by third parties.
+It is a security protocol that encrypts [[DNS]] queries and responses, enhancing privacy and security by preventing eavesdropping and tampering. In the context of [[0.Introduction|pkarr]], DoH plays a crucial role in ensuring that [[DNS]] queries made to resolve public-key addresses are secure and cannot be intercepted or manipulated by third parties.
 
 ### Key Points about DoH
 

Technologies/Key Pair.md

@@ -0,0 +1,42 @@
+A cryptography key pair consists of two related but distinct cryptographic keys:
+
+1. **Private Key**: A secret key that is used to decrypt, sign, or authenticate data. It's called "private" because it should be kept confidential and secure to prevent unauthorized access.
+2. **Public Key**: A publicly accessible key that is used to encrypt, verify, or authenticate data. It's called "public" because it can be shared freely without compromising the security of the system.
+
+### How do key pairs work?
+
+Here's a simplified overview of how key pairs are used in various cryptographic scenarios:
+
+#### Encryption
+
+- Alice wants to send a secure message to Bob.
+- Bob generates a key pair and shares his public key with Alice.
+- Alice uses Bob's public key to encrypt the message.
+- Bob uses his private key to decrypt the message.
+
+#### Digital Signatures
+
+- Alice wants to send a document to Bob and prove its authenticity.
+- Alice generates a key pair and uses her private key to sign the document.
+- Bob uses Alice's public key to verify the signature and ensure the document hasn't been tampered with.
+
+#### Authentication
+
+- Alice wants to access a secure system or service.
+- The system generates a key pair and shares its public key with Alice.
+- Alice uses the system's public key to encrypt a challenge or password.
+- The system uses its private key to decrypt the challenge or password and authenticate Alice.
+
+#### Key Pair Properties
+
+- **Asymmetric**: Key pairs are asymmetric, meaning that the private key is not easily derived from the public key.
+- **Mathematical relationship**: The private and public keys are mathematically related, allowing for encryption, decryption, signing, and verification.
+- **Unique**: Each key pair is unique, ensuring that data encrypted with a public key can only be decrypted with the corresponding private key.
+
+#### Types of Key Pairs
+
+- **RSA (Rivest-Shamir-Adleman)**: A popular algorithm used for encryption, decryption, and digital signatures.
+- **Elliptic Curve Cryptography (ECC)**: A more modern algorithm used for encryption, decryption, and digital signatures, offering better security with smaller key sizes.
+- **Diffie-Hellman (DH)**: A key exchange algorithm used to establish a shared secret key between two parties.
+
+In summary, cryptography key pairs are a fundamental component of secure online communications, enabling encryption, digital signatures, and authentication. By using a pair of related but distinct keys, key pairs provide a secure way to protect data and ensure its authenticity.

Technologies/Paykit.md

@@ -1 +1 @@
-Paykit abstracts and automates any payment method behind a single, static public key. The public key belongs to a Pubky instance and points to a [data store](1.Data%20Stores.md) containing all supported payment endpoints. Paykit enables applications where users pay directly to profiles, so offers a very intuitive experience, particularly when multiple payment methods are possible within the system.
+Paykit abstracts and automates any payment method behind a single, static public key. The public key belongs to a Pubky instance and points to a [data store](Data%20Stores.md) containing all supported payment endpoints. Paykit enables applications where users pay directly to profiles, so offers a very intuitive experience, particularly when multiple payment methods are possible within the system.

index.md

@@ -2,12 +2,13 @@
 
 ![[pubky_arch.png]]
 
-This is the [[0.index|Pubky Core]] and [[Pubky App|Pubky App]] knowledge base. Currently these docs are a mix of reality, dreams, visions, technicalities, actuality and plans.
+This is the [[Pubky Core/Introduction|Pubky Core]] and [[PubKy App/Introduction|Pubky App]] knowledge base. Currently these docs are a mix of reality, dreams, visions, technicalities, actuality and plans.
 
-1. Cloud storage with [[3.Credible Exit|credible exit]] (in the current implementation, it is just a web server + [[Pkarr/index|pkarr]])
+1. Cloud storage with [[3.Credible Exit|credible exit]] (in the current implementation, it is just a web server + [[0.Introduction|pkarr]])
 2. On top of that we build a [[1.Web of Trust|Web of Trust]]
-3. [[Pubky App|Pubky App]] is the main demonstration of how should this distributed data be crawled, indexed and searched at scale (albeit at a centralized setup).
+3. [[PubKy App/Introduction|Pubky App]] is the main demonstration of how should this distributed data be crawled, indexed and searched at scale (albeit at a centralized setup).
+4. By decoupling features from centralized control, independent development remains open and vibrant.
 
 ## Get Started
 
-A good place to start is the [[Pubky App|Pubky App]], [[TLDR]] or our pubky-core [[ELI5]]
+A good place to start is the [[PubKy App/Introduction|Pubky App]], [[TLDR]] or our pubky-core [[ELI5]]