import { Resources } from '@/components/Resources'
import { HeroPattern } from '@/components/HeroPattern'

export const metadata = {
    title: 'Lysand Documentation',
    description: 'Introduction to the Lysand Protocol, a communication medium for federated applications, leveraging the HTTP stack.',
}

export const sections = [
    { title: 'Vocabulary', id: 'vocabulary' },
    { title: 'Basic Concepts', id: 'basic-concepts' },
    { title: 'Resources', id: 'resources' },
]

<HeroPattern />

# Lysand Federation Protocol

The Lysand Protocol is designed as a communication medium for federated applications, leveraging the HTTP stack. Its simplicity ensures ease of implementation and comprehension. {{ className: 'lead' }}

<div className="not-prose mb-16 mt-6 flex gap-3">
  <Button href="/entities" arrow="right">
    <>Entities</>
  </Button>
  <Button href="/sdks" variant="outline">
    <>Explore SDKs</>
  </Button>
</div>

## Vocabulary

<Note>
The words **MUST**, **MUST NOT**, **SHOULD**, **SHOULD NOT**, and **MAY** are used in this document as defined in [RFC 2119](https://tools.ietf.org/html/rfc2119).
</Note>

The Lysand Protocol uses the following terms:
- **Entity**: A generic term for any JSON object in the protocol, such as an [Actor](./entities/actors), a [Note](./entities/notes), or a [Like](./entities/likes). Entities are uniquely identified by their `id` property.
- **Implementation**: A software application that implements the Lysand Protocol.
- **Instance**: An application deploying an **Implementation**.
  - Using the same nomenclature, an ActivityPub Implementation would be `Mastodon`, and an Instance would be `mastodon.social`.
- **Federation**: The process of exchanging data between two or more **Instances**.

## Philosophy

The Lysand Protocol is heavily inspired by the [ActivityPub](https://www.w3.org/TR/activitypub/) specification. It is designed to be simple and easy to implement, with a focus on the following concepts:
- **Simple Structures**: Entities are represented as JSON objects. No JSON-LD, no complex data structures, just plain JSON.
- **Modularity**: The protocol is divided into a **core protocol** and **extensions**. Implementations can choose to support only the core protocol or add extensions as needed.
- **Namespacing**: To avoid extension conflicts, all extensions are namespaced.
- **Signatures**: Most types of interactions **must** be signed with a private key. Unlike other protocols, signatures are **mandatory**, not optional.
- **Developer-Friendliness**: Understanding and implementing your own Lysand server should be easy. Documentation is aimed at developers first.

<Resources />