commits
by [the rkey
spec](https://atproto.com/specs/record-key#record-key-syntax):
> restricted to a subset of ASCII characters — the allowed characters
are alphanumeric (A-Za-z0-9), period, dash, underscore, colon, or tilde
(.-_:~)
tilde was missing from this check, which leads to at least [jetstream
becoming unhappy](https://github.com/bluesky-social/jetstream/issues/54)
over valid-but-uncommon rkeys.
this change aligns the check with the spec.
the tilde is before the hyphen (different order from the spec) to avoid the hyphen being treated as a regex range
by [the rkey spec](https://atproto.com/specs/record-key#record-key-syntax):
> restricted to a subset of ASCII characters — the allowed characters are alphanumeric (A-Za-z0-9), period, dash, underscore, colon, or tilde (.-_:~)
tilde was missing from this check, which leads to at least [jetstream becoming unhappy](https://github.com/bluesky-social/jetstream/issues/54) over valid-but-uncommon rkeys.
this change aligns the check with the spec.
Previously we forgot about the `neg` field in between these conversions.
Now we don't. With tests!
These are 2022-era docs written by @whyrusleeping
The feed notes stuff is out of date and uncontroversial to remove.
The JWT notes have info that is somewhat intentionally not documented
elsewhere: PDS implementations can put whatever they want in there. I
think self-hosted instances already maybe just use a UUID? But there
might be some cases/hacks where this is helpful. We could copy to
internal docs? I'd still push to remove, don't want lots of folks
building on this and it results in breakage or interop problems down the
line.
This is needed as part of the "adversarial PDS migration" flow, because
the existing `goat account service-auth` command requires the origin PDS
to create the token.
```
NAME:
goat account service-auth-offline - create service auth token via locally-held signing key
USAGE:
goat account service-auth-offline [command options] [arguments...]
OPTIONS:
--atproto-signing-key value private key used to sign the token (multibase syntax) [$ATPROTO_SIGNING_KEY]
--iss value the DID of the account issuing the token
--endpoint value, --lxm value restrict token to API endpoint (NSID, optional)
--audience value, --aud value DID of service that will receive and validate token
--duration-sec value validity time window of token (seconds) (default: 0)
--help, -h show help
```
Adds the following new subcommands to `goat plc`, for PLC identity
management without the involvement of a PDS:
```
genesis produce an unsigned genesis operation
calc-did calculate the DID corresponding to a signed PLC operation
sign sign an operation, ready to be submitted
submit submit a signed operation to the PLC directory
update apply updates to a previous operation produce a new one (but don't sign or submit it, yet)
```
I'm going to self-merge this to unblock a project
I think it's unnecessary to specify JSON format everywhere
I've wanted this when writing tests that use the mock directory from
multiple goroutines.
This lexgen's our latest types so we're up-to-date, and fixes up the
breaking changes that occurred as a result (just
`ModerationQueryEvents`, which has two new parameters).
Now `make lexgen` runs cleanly.
This fixes lexgen for empty unions (which it now treats similarly to
`unknown`).
Also handles the special "meta" unknown field in
`tools.ozone.moderation.defs#modTool`, which is a "true" unknown (aka,
it will not have `$type`, similar to plc ops and did docs).
I tested running against atproto main, and the API part worked, but
current lexgen adds yet more params to queryEvents which breaks things.
Don't have any specific burning need for this, just keeping up with
releases.
Go 1.25 is expected in August; we'll probably wait until at least
v1.25.1 and an Alpine release to upgrade.
- tries harder to find a valid handle in alsoKnownAs list (doesn't stop
at the first `at://` if it was not a valid handle)
- normalizes handles when extracting from DID docs / identities
- ensures that bi-directional handle comparisons are done with
normalized handles
- ensures that caching is done with normalized version of handles
- adds some tests for all this
We still rely on knowing whether a lookup was a cache hit or not in some
of our services.
Making a couple internal methods and types private, and gave a couple
sub-types better names.
These are technically API breaking changes, but i'm pretty confident the
internal bits are not being used outside this repo. And the renames
should also not be particularly disruptive (if at all), and best done
sooner than later (eg, before more folks start building on this API
surface).
Description:
This pull request corrects minor typos in documentation and inline
comments to improve clarity and maintain code quality.
by [the rkey
spec](https://atproto.com/specs/record-key#record-key-syntax):
> restricted to a subset of ASCII characters — the allowed characters
are alphanumeric (A-Za-z0-9), period, dash, underscore, colon, or tilde
(.-_:~)
tilde was missing from this check, which leads to at least [jetstream
becoming unhappy](https://github.com/bluesky-social/jetstream/issues/54)
over valid-but-uncommon rkeys.
this change aligns the check with the spec.
by [the rkey spec](https://atproto.com/specs/record-key#record-key-syntax):
> restricted to a subset of ASCII characters — the allowed characters are alphanumeric (A-Za-z0-9), period, dash, underscore, colon, or tilde (.-_:~)
tilde was missing from this check, which leads to at least [jetstream becoming unhappy](https://github.com/bluesky-social/jetstream/issues/54) over valid-but-uncommon rkeys.
this change aligns the check with the spec.
These are 2022-era docs written by @whyrusleeping
The feed notes stuff is out of date and uncontroversial to remove.
The JWT notes have info that is somewhat intentionally not documented
elsewhere: PDS implementations can put whatever they want in there. I
think self-hosted instances already maybe just use a UUID? But there
might be some cases/hacks where this is helpful. We could copy to
internal docs? I'd still push to remove, don't want lots of folks
building on this and it results in breakage or interop problems down the
line.
This is needed as part of the "adversarial PDS migration" flow, because
the existing `goat account service-auth` command requires the origin PDS
to create the token.
```
NAME:
goat account service-auth-offline - create service auth token via locally-held signing key
USAGE:
goat account service-auth-offline [command options] [arguments...]
OPTIONS:
--atproto-signing-key value private key used to sign the token (multibase syntax) [$ATPROTO_SIGNING_KEY]
--iss value the DID of the account issuing the token
--endpoint value, --lxm value restrict token to API endpoint (NSID, optional)
--audience value, --aud value DID of service that will receive and validate token
--duration-sec value validity time window of token (seconds) (default: 0)
--help, -h show help
```
Adds the following new subcommands to `goat plc`, for PLC identity
management without the involvement of a PDS:
```
genesis produce an unsigned genesis operation
calc-did calculate the DID corresponding to a signed PLC operation
sign sign an operation, ready to be submitted
submit submit a signed operation to the PLC directory
update apply updates to a previous operation produce a new one (but don't sign or submit it, yet)
```
This fixes lexgen for empty unions (which it now treats similarly to
`unknown`).
Also handles the special "meta" unknown field in
`tools.ozone.moderation.defs#modTool`, which is a "true" unknown (aka,
it will not have `$type`, similar to plc ops and did docs).
I tested running against atproto main, and the API part worked, but
current lexgen adds yet more params to queryEvents which breaks things.
- tries harder to find a valid handle in alsoKnownAs list (doesn't stop
at the first `at://` if it was not a valid handle)
- normalizes handles when extracting from DID docs / identities
- ensures that bi-directional handle comparisons are done with
normalized handles
- ensures that caching is done with normalized version of handles
- adds some tests for all this
Making a couple internal methods and types private, and gave a couple
sub-types better names.
These are technically API breaking changes, but i'm pretty confident the
internal bits are not being used outside this repo. And the renames
should also not be particularly disruptive (if at all), and best done
sooner than later (eg, before more folks start building on this API
surface).