oppi.li
bnewbold.net
-26
docs/auth.md
-26
docs/auth.md
···
1
-
# Auth
2
-
3
-
The auth system uses two tokens, an access token and a refresh token.
4
-
5
-
The access token is a jwt with the following values:
6
-
```
7
-
scope: "com.atproto.access"
8
-
sub: <the users DID>
9
-
iat: the current time, in unix epoch seconds
10
-
exp: the expiry date, usually around an hour, but at least 15 minutes
11
-
```
12
-
13
-
The refresh token is a jwt with the following values:
14
-
```
15
-
scope: "com.atproto.refresh"
16
-
sub: <the users DID>
17
-
iat: the current time, in unix epoch seconds
18
-
exp: the expiry date, usually around a week, must be significantly longer than the access token
19
-
jti: a unique identifier for this token
20
-
```
21
-
22
-
The access token is what is used for all requests, however since it expires
23
-
quickly, it must be refreshed periodically using the refresh token.
24
-
When the refresh token is used, it must be marked as deleted, and the new token then replaces it.
25
-
Note: The old access token is not necessarily disabled at that point of refreshing.
26
-
-37
docs/feed-proposal.md
-37
docs/feed-proposal.md
···
1
-
# Feed Structuring Proposal
2
-
3
-
Some thoughts on a new format for feeds.
4
-
5
-
## Motivation
6
-
The interface for requesting and getting back feeds is something that I feel is really at the core of what bluesky offers. The user should be able to choose what feeds they subscribe to, feeds should be first class objects, they should be able to be efficiently generated and consumed, and they should be able to trustlessly come from anywhere.
7
-
There are a lot of changes we *could* make to the current structure, but I don't want to stray too far from where we are at right now.
8
-
9
-
10
-
```go
11
-
type Feed struct {
12
-
Items []FeedItem
13
-
Values map[Cid]Record
14
-
ItemInfos map[Uri]ItemInfo
15
-
ActorInfos map[Did]ActorInfo
16
-
}
17
-
18
-
type FeedItem struct {
19
-
Uri string
20
-
Replies []Uri
21
-
ReplyTo Uri
22
-
RepostedBy Did
23
-
}
24
-
25
-
type ItemInfo struct {
26
-
Cid Cid
27
-
Upvotes int
28
-
Reposts int
29
-
Replies int
30
-
Author Did
31
-
}
32
-
```
33
-
34
-
The main idea here is not repeating ourselves, while still providing all the information the client might need.
35
-
With this structure too, the user could easily request *less* data, asking to
36
-
skip the inclusion of records older than X, or saying they are okay with stale
37
-
information in certain places for the sake of efficiency.