Write example app implementation

[cjslep]

Already occurring, but now tracked in this issue:

• 20b07c59c133123d8c0b41c5d02182843774279a
• aca6d80088f78cd7d4e8996f7241ff325c82c1f0

[ppwfx]

Hey @cjslep,

what's the state of the example app? Is there anything that's blocking you?

Other than that, enjoy your weekend :)

[cjslep]

Hi, I've written an update here: https://cjslep.com/c/blog/go-fed-2020

I am the blocker with not enough free time and too many things to focus on.

[cjslep]

Per the recent major refactor the example application is now majorly broken. However, there's going to be numerous design-type issues that need to be addressed before the example app can be fixed.

[cjslep]

I've been thinking of changing the example app to be a very minimal thin layer of an HTML renderer on top of the base apcore, so that folks can readily and easily use it as the basis for an actual application.

And I do mean minimal, was thinking of a cheeky name like "bland" for the example app (and go for a brutalist minimal CSS to go with it). Want to make it as straightforward to play with as possible.

[cjslep]

I'm taking this issue now -- I believe the library is of sufficient substance as to permit iterating on several different aspects while using a concrete exemplary use-case at hand. Note that a lot of the OAuth2 tasks are still available, and that's by design -- I believe there are some publicly available tools that can evaluate peer OAuth2 servers and aid in diagnosing their implementation. I believe that will be critical, because I am not entirely confident in the current state of the OAuth2 library I am using.

[cjslep]

b9b817abdbfd56fc73ade840b421752819f7526f makes the example application compile.

Though due to #46 that may change in the future.

This let me run the example configure, example init-db, and example init-admin actions and uncover issues within the software and fix ~9 issues.

Next may be an iteration on the app.Application interface before I attempt to keep fleshing out the remaining serving aspect of the example application, and from there it will be figuring out how to provide more features to the app.Application implementations.

[cjslep]

I've iterated on the app.Application, so I'm back to hammering out any bugs with example serve.

I ran into a problem with using v1.7.4 of gorilla/mux where their Schema matching was completely broken and would never match, so I had to upgrade to v1.8.0.

I've also "re"-remembered an improper assumption I had buried in go-fed/activity: https://github.com/go-fed/activity/issues/143

Which is not a problem for serving on a production server using https, only when attempting to serve with a -dev flag which uses http.

[cjslep]

With the changes to go-fed/activity, I'm testing hitting some of the framework-provided endpoints. Here's the state from quick testing, as further work to do (these are all GET requests):

• [x] /user/{id} successfully returns the actor's JSON-LD payload
• [x] /user/{id}/inbox has a nil dereference issue
• [x] /user/{id}/outbox has a nil dereference issue
• [x] /user/{id}/followers incorrectly returns the actor's JSON-LD payload
• [x] /user/{id}/following incorrectly returns the actor's JSON-LD payload
• [x] /user/{id}/liked incorrectly returns the actor's JSON-LD payload
• [x] /actors/instance is not yet mapped
• [x] /actors/instance/inbox has a nil dereference issue
• [x] /actors/instance/outbox has a nil dereference issue

I believe the nil dereference issues are related to the incomplete OAuth2 work (see sibling issues like #38) and the rest are more than likely the mux pattern matchers needing some tweaking.

[cjslep]

All of the above endpoints now successfully serve ActivityStreams data for GET http requests, their associated issues are resolved. Unfortunately, the POST side will only be easier to test once the rest of the example app is fleshed out.

Next up for the example application is ensuring the login and authentication aspects work correctly.

[cjslep]

Status update: as of yesterday, I got the example app to successfully federate locally (over loopback). It can:

• render latest public notes
• when logged in, render latest public and visible-to-user notes
• list actor public inbox/outbox/follower/following IRIs
• create a note

Which isn't too much. It's going to be pretty bare bones, but these are the remaining larger points I'd like to hit:

• [ ] A page to view Follow requests and, optionally, approve them
• [ ] Checkbox to +CC followers when creating a note
• [ ] Page to view preferences
• [ ] A way to update preferences
• [ ] Page to view personal policies (blocks)
• [ ] A way to update personal policies (blocks)
• [ ] Admin dashboard (resolutions, instance policies)
• [ ] A way to update admin (instance policies, ban local user, ban federated note, ban local note)

There will be a lot of follow-on work to smoothen out some of the API pain points once the above is done.