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.

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

Roadmap to V1 #5

Open
jdormit opened this Issue Jan 30, 2019 · 1 comment

Comments

Projects
None yet
2 participants
@jdormit
Copy link
Contributor

jdormit commented Jan 30, 2019

cc @squeevee

This issue is to track the stuff that still needs to get done before the library is ready for use. There are a few categories:

Core ActivityPub implementation

Every activity type that requires special handling needs a Handler class in ActivityPub\Activities, plus we'll need a handler to persist all incoming activities and a handler to deliver activities to other server (S2S federation). This will also involve implementing some plumbing elsewhere in the codebase (e.g., checking for blocks when receiving activities)

  • ActivityValidator
  • NonActivityHandler (wraps non-activities in Creates)
  • CreateHandler
  • UpdateHandler
  • DeleteHandler
  • FollowHandler
  • AcceptHandler
  • RejectHandler
  • AddHandler
  • RemoveHandler
  • LikeHandler
  • AnnounceHandler
  • BlockHandler
  • UndoHandler
  • ActivityPersister
  • ActivityDeliverer

Library API

Callers will probably want do ActivityPub stuff without having manually construct a Request and pass it to the request handler, so we should expose some API methods in ActivityPub.php - createActor, postActivity, etc.

  • Implement the public API

WebFinger

As discussed in #2, we need to implement an optional WebFinger API to make it easy for callers to participate in WebFinger discovery

  • Implement WebFinger

Caching

The current implementation could thrash the database pretty hard if a bunch of requests come in for the same id in a short amount of time, which is pretty common due to AP's federation model. We should put in a pluggable caching layer over ObjectsService::query that caches queries for particular ids, and invalidates the cache whenever the object referenced by that id changes (via replace, update, etc.). This will be a PSR-16-compatible Cache object that gets passed into ObjectsService. The cache will default to a PHP Cache filesystem cache, but we'll expose an option in the config that lets callers pass in any PSR16-compliant cache implementation, allowing them to use Memcached, Redis, etc.

  • Implement the caching layer

Integration (end-to-end) testing

Once the rest of the API is complete, I want to write some end-to-end tests that pass in various Requests and make sure that the database state is what we would expect, that the Response that gets returned is correct, etc.

  • Write integration tests

Next steps

Once the above items are done and tested, I would consider the library ready for preliminary use. Longer term, I also want to think about implementing a builder-pattern API for constructing AP activities and objects to make things a little more type-safe and elegant. I don't want a strict type system though, as that would make it more difficult to extend ActivityPub in client applications, so these builders would probably still return arrays that get passed into the existing library functions.

Any thoughts or suggestions are welcome!

@Cambridgeport90

This comment has been minimized.

Copy link

Cambridgeport90 commented Feb 25, 2019

This looks really sweet. I'm keeping an eye on this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.