Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

guides: remove all lexicon links #308

Merged
merged 1 commit into from
Mar 27, 2024
Merged

guides: remove all lexicon links #308

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions content/guides/applications.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,13 +9,13 @@ tldr:

# Applications model

Applications on the AT Protocol connect to the user's Personal Data Server (PDS) to access their account. Once a session is established, the app can use the [lexicons](./lexicon) implemented by the PDS to drive behaviors.
Applications on the AT Protocol connect to the user's Personal Data Server (PDS) to access their account. Once a session is established, the app can use the lexicons implemented by the PDS to drive behaviors.

In this guide, we'll step through a couple of common patterns (with simple code examples) to help you develop an intuition about this. All APIs shown below are generated using Lexicon's code-generator CLI.

## Signing in

Sign-in and authentication is a simple session-oriented process. The [com.atproto.server lexicon](/lexicons/com-atproto) includes APIs for creating and managing these sessions.
Sign-in and authentication is a simple session-oriented process. The `com.atproto.server.*` lexicons include APIs for creating and managing these sessions.

```typescript
// create an API instance with my PDS
Expand Down Expand Up @@ -75,7 +75,7 @@ If you're noticing the "type" field and wondering how that works, see the [Intro

You'll notice "cids" in some of the schemas. A "cid" is a "Content ID," a sha256 hash of some referenced content. These are used to ensure integrity; for instance, a like includes the cid of the post being liked so that a future edit can be detected and noted in the UI.

### <a href="/lexicons/app-bsky">app.bsky.graph.follow</a>
### `app.bsky.graph.follow`

A social follow. Example:

Expand All @@ -87,7 +87,7 @@ A social follow. Example:
}
```

### <a href="/lexicons/app-bsky">app.bsky.feed.like</a>
### `app.bsky.feed.like`

A like on a piece of content. Example:

Expand All @@ -102,7 +102,7 @@ A like on a piece of content. Example:
}
```

### <a href="/lexicons/app-bsky">app.bsky.feed.post</a>
### `app.bsky.feed.post`

A microblog post. Example:

Expand All @@ -114,7 +114,7 @@ A microblog post. Example:
}
```

### <a href="/lexicons/app-bsky">app.bsky.actor.profile</a>
### `app.bsky.actor.profile`

A user profile. Example:

Expand All @@ -126,7 +126,7 @@ A user profile. Example:
}
```

### <a href="/lexicons/app-bsky">app.bsky.feed.repost</a>
### `app.bsky.feed.repost`

A repost of an existing microblog post (similar to retweets). Example:

Expand Down
4 changes: 2 additions & 2 deletions content/guides/identity.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -53,7 +53,7 @@ The DNS handle is a user-facing identifier — it should be shown in UIs and pro
<tr>
<td><strong>Handles</strong>
</td>
<td>Handles are DNS names. They are resolved using the <a href="/lexicons/com-atproto">com.atproto.identity.resolveHandle()</a> XRPC method and should be confirmed by a matching entry in the DID document. Details in the <a href="/specs/handle">Handle specification</a>.
<td>Handles are DNS names. They are resolved using the `com.atproto.identity.resolveHandle` XRPC method and should be confirmed by a matching entry in the DID document. Details in the <a href="/specs/handle">Handle specification</a>.
</td>
</tr>
<tr>
Expand Down Expand Up @@ -94,7 +94,7 @@ At present, none of the DID methods meet our standards fully. **Therefore, we ha

Handles in atproto are domain names which resolve to a DID, which in turn resolves to a DID Document containing the user's signing pubkey and hosting service.

Handle resolution uses the [`com.atproto.identity.resolveHandle`](/lexicons/com-atproto) XRPC method. The method call should be sent to the server identified by the handle, and the handle should be passed as a parameter.
Handle resolution uses the `com.atproto.identity.resolveHandle` XRPC method. The method call should be sent to the server identified by the handle, and the handle should be passed as a parameter.

Here is the algorithm in pseudo-TypeScript:

Expand Down
2 changes: 1 addition & 1 deletion content/guides/overview.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ The lower-level primitives that can get stacked together differently are the rep

## Interoperation

A global schemas network called [Lexicon](/specs/lexicon) is used to unify the names and behaviors of the calls across the servers. Servers implement "lexicons" to support featuresets, including the core [ATP Lexicon](/lexicons/com-atproto) for syncing user repositories and the [Bsky Lexicon](/lexicons/app-bsky) to provide basic social behaviors.
A global schemas network called [Lexicon](/specs/lexicon) is used to unify the names and behaviors of the calls across the servers. Servers implement "lexicons" to support featuresets, including the core `com.atproto.*` lexicons for syncing user repositories and the `app.bsky.*` lexicons to provide basic social behaviors.

![Interop](/img/interop.jpg)

Expand Down