diff --git a/.export-ignore b/.export-ignore index b651cf8..7bab13a 100644 --- a/.export-ignore +++ b/.export-ignore @@ -1,3 +1,4 @@ .obsidian/* Readme.md -quartz \ No newline at end of file +quartz +quartz/* \ No newline at end of file diff --git a/.obsidian/app.json b/.obsidian/app.json index 9e26dfe..f7675d2 100644 --- a/.obsidian/app.json +++ b/.obsidian/app.json @@ -1 +1,9 @@ -{} \ No newline at end of file +{ + "userIgnoreFilters": [ + "quartz/", + "quartz/node_modules/", + "quartz/public/", + "quartz/*" + ], + "alwaysUpdateLinks": true +} \ No newline at end of file diff --git a/.obsidian/graph.json b/.obsidian/graph.json index 42a46ec..b2d26fa 100644 --- a/.obsidian/graph.json +++ b/.obsidian/graph.json @@ -17,6 +17,6 @@ "repelStrength": 10, "linkStrength": 1, "linkDistance": 250, - "scale": 1, + "scale": 0.2962962962962961, "close": true } \ No newline at end of file diff --git a/.obsidian/workspace.json b/.obsidian/workspace.json index 10a2564..1656a28 100644 --- a/.obsidian/workspace.json +++ b/.obsidian/workspace.json @@ -4,15 +4,19 @@ "type": "split", "children": [ { - "id": "7d1f92f7f9f039d2", + "id": "096ff39c8b3a2932", "type": "tabs", "children": [ { - "id": "2eac11a4f2c0514b", + "id": "8fd5812ca70f0ab7", "type": "leaf", "state": { - "type": "empty", - "state": {} + "type": "markdown", + "state": { + "file": "concepts/Web of Trust.md", + "mode": "source", + "source": false + } } } ] @@ -81,6 +85,7 @@ "state": { "type": "backlink", "state": { + "file": "concepts/Web of Trust.md", "collapseAll": false, "extraContext": false, "sortOrder": "alphabetical", @@ -97,6 +102,7 @@ "state": { "type": "outgoing-link", "state": { + "file": "concepts/Web of Trust.md", "linksCollapsed": false, "unlinkedCollapsed": true } @@ -118,7 +124,9 @@ "type": "leaf", "state": { "type": "outline", - "state": {} + "state": { + "file": "concepts/Web of Trust.md" + } } } ] @@ -135,17 +143,51 @@ "canvas:Create new canvas": false, "daily-notes:Open today's daily note": false, "templates:Insert template": false, - "command-palette:Open command palette": false + "command-palette:Open command palette": false, + "hide-folders:Show hidden folders": false } }, - "active": "2eac11a4f2c0514b", + "active": "8fd5812ca70f0ab7", "lastOpenFiles": [ - "Readme.md", - "pubky-social/pubky-social.md", + "quartz/public/404.html", + "quartz/public/quartz/quartz/plugins/transformers/toc.ts", + "quartz/public/quartz/quartz/plugins/transformers/syntax.ts", + "quartz/public/quartz/quartz/plugins/transformers/oxhugofm.ts", + "quartz/public/quartz/quartz/plugins/transformers/ofm.ts", + "quartz/public/quartz/quartz/plugins/transformers/links.ts", + "quartz/public/quartz/quartz/plugins/transformers/linebreaks.ts", + "quartz/public/quartz/quartz/plugins/transformers/latex.ts", + "quartz/public/quartz/quartz/plugins/transformers/lastmod.ts", + "quartz/public/quartz/quartz/plugins/transformers/index.ts", + "quartz/public/quartz/quartz/plugins/transformers/gfm.ts", + "quartz/public/quartz/quartz/static/og-image.png", + "quartz/public/quartz/quartz/static/icon.png", + "quartz/public/static/og-image.png", + "quartz/public/static/icon.png", + "pubky-app.md", + "pubky.app.md", + "Pubky.app.md", + "concepts/Web of Trust.md", + "concepts/Web of Trust.md", + "concepts/Credible Exit.md", + "concepts/Censorship.md", + "pkarr/Why Pkarr.md", + "pubky-core/Protocols.md", + "pubky-core/Data Stores.md", + "technologies/Paykit.md", + "pubky-core/Data.md", + "data store.md", + "technologies/Mainline DHT.md", + "pubky-core/Applications.md", "pubky-core/pubky-core.md", - "pubky-social", - "pubky-core", - "Welcome.md", - "README.md" + "index.md", + "technologies/HTTPS.md", + "technologies/DoH.md", + "technologies/DNS.md", + "technologies/DHT.md", + "related-tech/Mainline DHT.md", + "related-tech/DHT.md", + "related-tech/DNS.md", + "pkarr/Why Pkarr?.md" ] } \ No newline at end of file diff --git a/ELI5.md b/ELI5.md new file mode 100644 index 0000000..8332f56 --- /dev/null +++ b/ELI5.md @@ -0,0 +1,7 @@ +## ELI5: Pubky Explained for Children + +Pubky is like a school where instead of one principal running the whole school, different teachers run classrooms by their own. + +The "teachers" ([[data stores]]) host all the students' school work. The "janitors" ([[aggregators]]) help move the work between classrooms so everyone can see it. + +The "lunch lady" ([[feeds]]) puts together trays of work for everyone to look at during recess. And the "librarian" ([[search]]) helps you find specific things across the student's works. diff --git a/Readme.md b/Readme.md index 33b86ac..14252bc 100644 --- a/Readme.md +++ b/Readme.md @@ -2,7 +2,9 @@ ## Add Knowledge -The top directory of this repo `/` is an Obsidian Vault. Just add Pubky knowledge to it. +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 diff --git a/TLDR.md b/TLDR.md new file mode 100644 index 0000000..c7e53f7 --- /dev/null +++ b/TLDR.md @@ -0,0 +1,10 @@ +## TLDR; [pubky.app](pubky-app) in Brief + +[pubky.app](pubky-app) is a decentralized alternative to social media platforms like Twitter. It uses a distributed architecture where: + +- Users host their own data on independent [[data stores]] +- Services [aggregate](pubky-core/Aggregators.md) data across stores into a unified view +- [[Feeds]] and search present curated views of the aggregated data +- [Application](pubky-core/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. diff --git a/concepts/Censorship.md b/concepts/Censorship.md new file mode 100644 index 0000000..c087f77 --- /dev/null +++ b/concepts/Censorship.md @@ -0,0 +1,17 @@ +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 + +Censorship can take many forms, from the simple act of removing content from public view to more sophisticated methods like deepfakes and disinformation campaigns. It can be enforced by governments, corporations, or even individuals, often with the intention of controlling narratives, suppressing dissent, or protecting commercial interests. + +## Impact on Freedom of Expression + +The internet was hailed as a tool for democratizing information and fostering freedom of expression. However, censorship poses a significant threat to these ideals. It can stifle the flow of ideas, suppress dissenting voices, and create echo chambers where only certain perspectives are heard. + +## Challenges + +In the digital age, censorship is not just about blocking access to information. It's about navigating a landscape where information can be manipulated, where identities can be stolen, and where privacy is increasingly under threat. The challenge lies in finding ways to protect freedom of expression and privacy in the face of these threats. + +## The Role of Technology + +Technology plays a crucial role in both enabling and combating censorship . On one hand, it provides tools and platforms for the dissemination of information. On the other hand, it can be used to censor content, track users, and manipulate public opinion. The key is to leverage technology in a way that supports freedom, transparency, and accountability. diff --git a/concepts/Credible Exit.md b/concepts/Credible Exit.md new file mode 100644 index 0000000..040568c --- /dev/null +++ b/concepts/Credible Exit.md @@ -0,0 +1,24 @@ +Credible exit 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: + +## Examples of Credible Exit + +- **[[DNS]]**: Allows users to move domain names between hosting providers, preventing vendor lock-in and promoting competition. +- **Email**: Offers the ability to switch between email service providers and save emails locally, enhancing user control over personal data. +- **Podcasts**: Supports importing and exporting subscriptions, facilitating easy transition between platforms. +- **Mirror.xyz**: Utilizes distributed protocols for data replication and storage, ensuring data can be reconstructed without relying on central services. +- **GitHub**: Provides credible exit for code through Git, allowing users to clone repositories and contribute to open-source projects. +- **Mastodon**: Enables federation between different instances, allowing users to move between servers without losing their data. + +## Important Aspects of Credible Exit + +- **Protocols**: The foundation of credible exit, enabling communication and data transfer between systems. +- **Data Importance**: Differentiating between basic data (content created by users) and generated data (interactions, likes, comments), which may require different approaches for exit. +- **Dimensions of Credible Exit**: Including the ability to export data, sync data across platforms, use data in useful formats, and store data in local files. + +## Challenges and Considerations + +- **Static Exports**: While GDPR regulations allow for data exports, the static nature of these exports can limit their utility for ongoing use. +- **Data Formats**: The importance of using common, useful formats for data to ensure it can be utilized elsewhere. +- **Interoperability**: The potential for multiple apps to share data through permissionless APIs, enhancing broad interoperability. diff --git a/concepts/Web of Trust.md b/concepts/Web of Trust.md new file mode 100644 index 0000000..b3bd652 --- /dev/null +++ b/concepts/Web of Trust.md @@ -0,0 +1,5 @@ +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. + +The concept, first introduced by PGP creator Phil Zimmermann in 1992, allows users to accumulate keys from others and designate them as trusted introducers. Over time, users distribute a collection of certifying signatures with their keys, expecting that anyone receiving these will trust at least one or two of the signatures. This process leads to the emergence of a decentralized, fault-tolerant web of confidence for all public keys, enabling a peer-to-peer rating system that verifies public keys and their owners without relying on a central identity authority. diff --git a/index.md b/index.md index c07721b..5c352b1 100644 --- a/index.md +++ b/index.md @@ -1,7 +1,13 @@ --- -title: Welcome to Pubky Knowledge Base +title: Welcome to the Pubky Knowledge Base --- -# Pubky Knowledge Base +This is the [[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]] and [[pubky-social]] knowledge base. +1. Cloud storage with [[Credible Exit]] (in the current implementation it is just a web server + [[Pkarr]].org) +2. On top of that we build a [[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). + +## Get Started + +A good place to start is the [pubky.app](pubky-app) [[TLDR]] or our pubky-core [[ELI5]] diff --git a/pkarr/Architecture.md b/pkarr/Architecture.md new file mode 100644 index 0000000..9c82177 --- /dev/null +++ b/pkarr/Architecture.md @@ -0,0 +1,19 @@ +In-depth look at the architecture of [[Pkarr]], including its components and how they interact. + +## Components + +- **Client**: Applications or users that publish or query resource records. +- **Relay**: Optional intermediary that helps clients behind NAT or firewall to communicate with the [[DNS]]. +- **[[DNS]]**: The overlay network used for storing and retrieving resource records. +- **Republisher**: Services that keep resource records alive on the [[DNS]] by periodically republishing them. + +## Interaction Flow + +1. **Publishing**: Clients publish resource records to the [[DNS]] through a relay. +2. **Republishing**: Clients can request republishing of their records to ensure they remain available on the [[DNS]]. +3. **Querying**: Clients query the [[DNS]] for resource records, either directly or through a relay. + +## Key Technologies + +- **[[Mainline DHT]]**: Pkarr uses the Mainline [[DNS]] as its overlay network, specifically BEP44 for storing ephemeral data. +- **[[DNS]] over [[HTTPS]] ([[DoH]])**: For applications unaware of Pkarr, DoH is used to resolve domains. diff --git a/pkarr/Expectations.md b/pkarr/Expectations.md new file mode 100644 index 0000000..cf826a6 --- /dev/null +++ b/pkarr/Expectations.md @@ -0,0 +1,21 @@ +Understanding the expectations and limitations of [[Pkarr]] is crucial for effective use. This note outlines what [[Pkarr]] is not and what users should expect. + +## Not a Storage Platform + +[[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 + +[[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 [[Pkarr]] was created and its motivation, refer to the [[Why Pkarr?]] note. diff --git a/pkarr/Getting Started with Pkarr.md b/pkarr/Getting Started with Pkarr.md new file mode 100644 index 0000000..2e8f278 --- /dev/null +++ b/pkarr/Getting Started with Pkarr.md @@ -0,0 +1,21 @@ +This guide will help you understand how to publish and resolve resource records using [[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 [[Pkarr]] can make normal [[DNS]] Queries over [[HTTPS]] ([[DoH]]) to [[Pkarr]] servers. + +## Caching and Scalability + +Clients and [[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 [[Pkarr]]'s architecture and how it works, refer to the [[Architecture]] note. diff --git a/pkarr/Pkarr.md b/pkarr/Pkarr.md new file mode 100644 index 0000000..1112474 --- /dev/null +++ b/pkarr/Pkarr.md @@ -0,0 +1,44 @@ +## Public-Key Addressable Resource Records + +Pkarr is a revolutionary system that bridges the gap between the Domain Name System ([[DNS]]) and peer-to-peer overlay networks. It allows self-issued public keys to function as sovereign, publicly addressable domains. This means that anyone with a private key can have a domain that is accessible to everyone. + +The core idea is to streamline the process of publishing and resolving resource records for keys, leveraging the Distributed Hash Table ([[DHT]]) for efficient and scalable data distribution. + +## Key Features + +- **Simplicity**: Pkarr streamlines the integration between [[DNS]] and peer-to-peer networks. +- **Sovereignty**: Public keys can be used as domains, enabling users to maintain control over their digital identities. +- **Accessibility**: The system is designed to be accessible to anyone capable of maintaining a private key. +- **Scalability and Resilience**: Designed with scalability and resilience in mind, using the [[Mainline DHT]] for storing ephemeral data, and employing caching strategies to minimize [[DHT]] traffic. +- **Compatibility with Existing Applications**: Supports existing applications through [[DNS]] over [[HTTPS]] (DoH) queries to Pkarr servers, ensuring broad compatibility. + +## How It Works + +1. **Publishing Records**: To publish resource records for a key, create a small encoded [[DNS]] packet (<= 1000 bytes), sign it, and publish it on the DHT. This can be done directly or through a relay if necessary. +2. **Resolving Records**: To find resources associated with a key, applications can query the [[DHT]] directly or through a relay, verifying the signature themselves. +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. + +## Getting Started + +[To start using Pkarr](/pkarr/Getting%20Started%20with%20Pkarr.md), you can visit the [web app demo](https://app.pkarr.org) or explore the Rust examples provided in [Pkarr repository](https://github.com/Nuhvi/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 Pkarr can make normal [[DNS]] Queries over [[HTTPS]] ([[DoH]]) to Pkarr servers. + +### Caching and Scalability + +Clients and 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 Pkarr's architecture and how it works, refer to the [[Architecture]] note. diff --git a/pkarr/Why Pkarr.md b/pkarr/Why Pkarr.md new file mode 100644 index 0000000..8dc584f --- /dev/null +++ b/pkarr/Why Pkarr.md @@ -0,0 +1,21 @@ +This section explores the motivation behind Pkarr, addressing the challenges of distributed semantics, databases, and discovery. + +## Distributed Semantics + +Pkarr aims to develop interoperable semantics for verifiable metadata about public keys, forming a digital identity with reputation, social graph, credentials, and more. + +## Distributed Databases + +The system supports a host-agnostic database essential for an open web, moving away from walled gardens. + +## Distributed Discovery + +Addressing distributed discovery first helps solve the most pressing issues and provides a foundation for solving the others. + +## Leveraging Pkarr + +Pkarr addresses unavailability, [[Censorship]] , deplatforming, and key management with minimal effort, leveraging existing technologies like [[Mainline DHT]] and web servers. + +## Next Steps + +For frequently asked questions and further clarifications, refer to the [FAQ](file.md) section. diff --git a/pkarr/Why Pkarr?.md b/pkarr/Why Pkarr?.md new file mode 100644 index 0000000..07110c2 --- /dev/null +++ b/pkarr/Why Pkarr?.md @@ -0,0 +1,17 @@ +This note explores the motivation behind Pkarr, addressing the challenges of distributed semantics, databases, and discovery. + +## Distributed Semantics + +Pkarr aims to develop interoperable semantics for verifiable metadata about public keys, forming a digital identity with reputation, social graph, credentials, and more. + +## Distributed Databases + +The system supports a host-agnostic database essential for an open web, moving away from walled gardens. + +## Distributed Discovery + +Addressing distributed discovery first helps solve the most pressing issues and provides a foundation for solving the others. + +## Leveraging Pkarr + +Pkarr addresses unavailability, [[[[censorship]] ]], deplatforming, and key management with minimal effort, leveraging existing technologies like [[Mainline DHT]] and web servers. diff --git a/pubky-app.md b/pubky-app.md new file mode 100644 index 0000000..d211a18 --- /dev/null +++ b/pubky-app.md @@ -0,0 +1,19 @@ +## Pubky.app Social Media + +Pubky-app's initial focus is building a decentralized social media protocol. Key aspects include: + +- User profiles hosted on [[Data Stores]] + +- Post/comment/like data stored with profiles + +- [[Aggregators]] collecting social graphs + +- [[Feeds]] of followings' activities + +- [[Search]]ing profiles and posts + +- Notification delivery through [Application](pubky-core/Applications) Backends + +- Distributed moderation through [user blocking](concepts/Web%20of%20Trust.md) + +The goal is to recreate core social features without dependence on any centralized company or platform. diff --git a/pubky-core/Adoption.md b/pubky-core/Adoption.md new file mode 100644 index 0000000..3598752 --- /dev/null +++ b/pubky-core/Adoption.md @@ -0,0 +1,21 @@ +## Pubky Adoption + +Realizing the full potential of Pubky relies on network effects through mainstream user onboarding: + +- Legacy centralized imports ease migration paths for established communities and profiles. + +- Simplified wallet and key management avoids barriers through friendly UX. + +- Default public profiles paired with granular privacy encourage open participation. + +- Progressive web apps maintain familiar experience across any device. + +- Incentivized discovery games spark initial engagements like following interesting accounts. + +- Federation with aligned systems like Mastodon expands the userbase through existing clusters. + +- Grassroots developers support localized languages/cultures for global inclusion. + +- Documentation, scholarships and bounties lower the skill floor for contributing back to protocols. + +The goal is surfacing the empowering aspects of decentralization to everyone. diff --git a/pubky-core/Aggregators.md b/pubky-core/Aggregators.md new file mode 100644 index 0000000..221293f --- /dev/null +++ b/pubky-core/Aggregators.md @@ -0,0 +1,17 @@ +## Pubky Aggregators + +Aggregators collect and normalize social data from multiple [[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 Stores. + +- Normalized data schemas support interoperability between services. + +- Public aggregators operate at scale for discoverability, while smaller niche aggregates also exist. + +- [[Censorship]] resistance comes from distributing aggregation across independent operators. + +- Microservices enable modular aggregation of different data types (profiles, posts, comments, etc). diff --git a/pubky-core/Applications.md b/pubky-core/Applications.md new file mode 100644 index 0000000..68b2390 --- /dev/null +++ b/pubky-core/Applications.md @@ -0,0 +1,17 @@ +Apps build specialized frontends tailored for specific workflows or platforms. + +## Pubky Applications + +Application Backends power features by integrating aggregated data: + +- [[Feeds]] curate timelines, hashtags, profiles and notify users. + +- [[Search]] indexes enable full-text/attribute queries across user profiles and content. + +- Communities facilitate moderation and discovery around shared interests. + +- [Payments](/technologies/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. diff --git a/pubky-core/Data Stores.md b/pubky-core/Data Stores.md new file mode 100644 index 0000000..bfb1940 --- /dev/null +++ b/pubky-core/Data Stores.md @@ -0,0 +1,17 @@ +## 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. + +- Stores provide access to data through an API, 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 stores. + +- [[Incentives]] encourage availability through services fees or peer-to-peer micropayments. + +- Data control remains with users even if a store goes offline through credible exit options. diff --git a/pubky-social/pubky-social.md b/pubky-core/Feeds.md similarity index 100% rename from pubky-social/pubky-social.md rename to pubky-core/Feeds.md diff --git a/pubky-core/Incentives.md b/pubky-core/Incentives.md new file mode 100644 index 0000000..7357c27 --- /dev/null +++ b/pubky-core/Incentives.md @@ -0,0 +1,17 @@ +## Pubky Incentives + +For the Pubky ecosystem to function at scale, it relies on incentives that encourage participation and uphold the user experience: + +- Data storage fees pay stores for availability and throughput. + +- Tipping and subscriptions reward high-quality contributors and curators. + +- Advertising supports free-tier services and indexes through contextual/non-intrusive formats. + +- Validation bonds and slashing conditions secure protocol compliance. + +- Data marketplace sales enable professional content creators to profit directly. + +- Job boards and service directories create opportunities within the emerging peer-to-peer economy. + +Together, these push the system towards collective benefit over individual maximization. diff --git a/pubky-core/Protocols.md b/pubky-core/Protocols.md new file mode 100644 index 0000000..d0cbbc1 --- /dev/null +++ b/pubky-core/Protocols.md @@ -0,0 +1,15 @@ +## Pubky Protocols + +Pubky is defined by several open protocols that enable independent implementations: + +**Pubky Data** - Definition of normalized data schemas for user profiles, content types, relationships etc. Allows unified querying across services. + +**Pubky Sync** - Mechanism for efficiently synchronizing incremental changes between data stores, aggregators, and consumers using Merkle trees. + +**Pubky Search** - Format for full-text search indices and queries across aggregated Pubky Data. Enables cross-platform discovery. + +**Pubky Payments** - Decentralized and interoperable payment protocol for microtransactions like tips, subscriptions and purchasing goods/services. + +**Pubky Identity** - Self-sovereign digital credentials for authentication without centralized authorities like usernames/passwords. + +**Pubky Federation** - Standard for distributed moderation and cross-instance relationships between interconnected but independent communities. diff --git a/pubky-core/Search.md b/pubky-core/Search.md new file mode 100644 index 0000000..e69de29 diff --git a/pubky-core/pubky-core.md b/pubky-core/pubky-core.md index d433331..e894050 100644 --- a/pubky-core/pubky-core.md +++ b/pubky-core/pubky-core.md @@ -1,12 +1,17 @@ -Something SomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomething Something -Something SomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomething Something -Something SomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomething Something -Something SomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomething Something -Something SomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomething Something -Something SomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomething Something -Something SomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomething Something -Something SomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomething Something -Something SomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomething Something -Something SomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomething Something -Something SomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomething Something -Something SomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomethingSomething Something +## Pubky Core Overview + +Pubky is built on a few core concepts: + +- **[[Data Stores]]** - Decentralized data storage nodes that host user data. Data is encrypted at rest. + +- **[[Aggregators]]** - Services that collect and aggregate data from multiple [[Data Stores]] into a single normalized view. + +- **[[Feeds]]** - Curated views of aggregated data presented to users. Can include timelines, hashtags, profiles, etc. + +- **[[Search]]** - Services that index aggregated data and enable full text/attribute searches. + +- **[Application Backends](/pubky-core/Applications.md)** - Backend services that integrate feeds, search, and user interfaces/configurations. + +- **[[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 [[Credible Exit]] between interchangeable components. diff --git a/quartz/.gitignore b/quartz/.gitignore new file mode 100644 index 0000000..468143b --- /dev/null +++ b/quartz/.gitignore @@ -0,0 +1,10 @@ +.DS_Store +node_modules +public +prof +tsconfig.tsbuildinfo +.obsidian +.quartz-cache +private/ +.replit +replit.nix diff --git a/quartz/package.json b/quartz/package.json index cacdc10..62a8a3f 100644 --- a/quartz/package.json +++ b/quartz/package.json @@ -13,6 +13,7 @@ }, "scripts": { "docs": "npx quartz build --serve -d ..", + "build": "npx quartz build -d ..", "check": "tsc --noEmit && npx prettier . --check", "format": "npx prettier . --write", "test": "tsx ./quartz/util/path.test.ts && tsx ./quartz/depgraph.test.ts", diff --git a/technologies/DHT.md b/technologies/DHT.md new file mode 100644 index 0000000..22a17f6 --- /dev/null +++ b/technologies/DHT.md @@ -0,0 +1,26 @@ +Distributed Hash Table (DHT) is a decentralized key-value store that allows for efficient data retrieval in a distributed system. Unlike traditional databases, DHTs do not rely on a central server to manage data. Instead, they use a hash function to map keys to nodes in the network, enabling data to be stored and retrieved across multiple nodes. + +A relevant example of [[DHT]] for Pubky is the [[Mainline DHT]] that is used primarily by the BitTorrent Network. + +## Key Features + +- **Decentralization**: DHTs operate without a central authority, making them highly resilient to failures and [[Censorship]] . +- **Scalability**: They can easily scale to accommodate more data and users by adding more nodes to the network. +- **Efficiency**: By distributing data across multiple nodes, DHTs can provide fast access to data without the need for a central server. + +## Applications + +DHTs are widely used in various applications, including: + +- **P2P Networks**: They are the backbone of peer-to-peer (P2P) networks, enabling the sharing of files and resources among users. +- **Content Delivery Networks (CDNs)**: DHTs help in efficiently distributing content across a global network of servers, improving load balancing and reducing latency. + +## Challenges + +Despite their advantages, DHTs face several challenges, including: + +- **Security**: Ensuring data privacy and integrity in a decentralized environment. +- **Consistency**: Achieving consistency across the distributed network, especially in the presence of node failures or network partitions. +- **Performance**: Balancing the trade-off between data distribution and access latency. + +DHTs represent a significant advancement in distributed systems, offering a scalable and efficient solution for data storage and retrieval in decentralized environments. diff --git a/technologies/DNS.md b/technologies/DNS.md new file mode 100644 index 0000000..ee5828b --- /dev/null +++ b/technologies/DNS.md @@ -0,0 +1 @@ +The Domain Name System (DNS) translates human-readable domain names (e.g., www.example.com) into IP addresses that computers use to identify each other on the network. This process simplifies internet navigation by allowing users to access websites using memorable names instead of numerical addresses. diff --git a/technologies/DoH.md b/technologies/DoH.md new file mode 100644 index 0000000..0b0d967 --- /dev/null +++ b/technologies/DoH.md @@ -0,0 +1,8 @@ +[[DNS]] over [[[[HTTPS]]]] (DoH) is a security protocol that encrypts [[DNS]] queries and responses, enhancing privacy and security by preventing eavesdropping and tampering. In the context of [[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 + +- **Encryption**: DoH encrypts [[DNS]] traffic, making it unreadable to anyone who might intercept the data. This is achieved by sending [[DNS]] queries and responses over [[[[HTTPS]]]] connections, utilizing port 443, the standard port for [[[[HTTPS]]]] traffic [2][3]. +- **Privacy and Security**: By encrypting [[DNS]] queries, DoH significantly increases privacy and security. It prevents Internet Service Providers (ISPs), governments, and hackers from monitoring or altering [[DNS]] requests [3]. +- **Standardization and Adoption**: DoH has been adopted by major internet brands, including Apple, Microsoft, and Google, to enhance online security. It was first implemented by Mozilla in 2018, and since then, it has become a standard for secure [[DNS]] communication [3]. +- **Compatibility and Implementation**: DoH can be enabled in browsers and operating systems, allowing users to benefit from its privacy and security features. However, it's important to ensure compatibility with existing cybersecurity solutions, as enabling DoH might impact [[DNS]] traffic filtering tools [3]. diff --git a/technologies/HTTPS.md b/technologies/HTTPS.md new file mode 100644 index 0000000..7ce4c52 --- /dev/null +++ b/technologies/HTTPS.md @@ -0,0 +1,7 @@ +HTTPS (Hypertext Transfer Protocol Secure) is an extension of HTTP that encrypts communication over a computer network, enhancing security and privacy. It uses TLS (Transport Layer Security) or SSL (Secure Sockets Layer) for encryption, protecting against eavesdropping and tampering. HTTPS is essential for securely transmitting sensitive data, such as login credentials and financial transactions, ensuring the authenticity of websites and the privacy of user communications. + +## Key Features + +- **Encryption**: Secures data in transit using TLS/SSL, making it unreadable to interceptors. +- **Authentication**: Verifies the identity of websites and services using digital certificates, ensuring users are communicating with the intended party. +- **Protection**: Guards against man-in-the-middle attacks and [[DNS]] spoofing, safeguarding user data and privacy. diff --git a/technologies/Mainline DHT.md b/technologies/Mainline DHT.md new file mode 100644 index 0000000..67d0458 --- /dev/null +++ b/technologies/Mainline DHT.md @@ -0,0 +1,12 @@ +Mainline [[DHT]] is a standard Distributed Hash Table (DHT) implementation widely used in the BitTorrent network, based on the [Kademlia](https://en.wikipedia.org/wiki/Kademlia) protocol. This decentralized system allows for efficient data storage and retrieval across a vast network of nodes, making it highly resilient and scalable. + +## Key Features + +- **Decentralization**: [[Mainline DHT]] operates without a central authority, enhancing its resilience against failures and [[Censorship]] . +- **Scalability**: It can easily scale to accommodate more data and users by adding more nodes to the network. +- **Efficiency**: By distributing data across multiple nodes, [[Mainline DHT]] provides fast access to data without the need for a central server. + +## Applications + +- **BitTorrent Network**: [[Mainline DHT]] adds tracker capabilities to each peer in the BitTorrent network, enhancing its resilience and reducing dependency on centralized trackers. +- **Peer-to-Peer File Sharing**: Beyond BitTorrent, DHTs like Mainline are used for instant messaging, name resolution, and other peer-to-peer file sharing applications. diff --git a/technologies/Paykit.md b/technologies/Paykit.md new file mode 100644 index 0000000..76b9a5f --- /dev/null +++ b/technologies/Paykit.md @@ -0,0 +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](pubky-core/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.