Cory J Slep
Cory J Slep
The idea is that the tool would do the existing steps: * Generate ActivityStreams types using the v1 code generation tool * Build an App against that, using types as...
If an implementation does not return a context in `AuthenticateGetOutbox` or `AuthenticateGetOutbox`, we propagate that `nil` context instead of returning an error.
It remains to be seen how the community of not-really-linked-data implementations (which includes go-fed right now) will handle ActivityPub extensions. For example, will types be like: ``` { "@context": [...
As part of [this change](https://github.com/go-fed/activity/issues/123#issuecomment-544691957) on two separate occasions I copied/pasted code in two places in the `converter.go` file. They're marked with `TODO`s Each could be unified into a single...
Right now only server origin is checked for `Update` and `Delete` federated activities received in the `inbox`. Permit users to specify `server` constraint or `actor` constraint.
Ensure ranges and domains are inherited at generation time.
Right now when resolving inboxes, the implementation can properly handle (Ordered) Collections. However, it does not support pagination.
Right now there's duplication of data in `Kind`, leftover from countless hours of experimentation. Clean it up.
Since Types have a TitleCase name, the "LowerName" field is not accurate.