Commit graph

240 commits

Author SHA1 Message Date
Pere Lev
ea463703b5
Upgrade actor system, now using HList, to allow per-actor method type 2024-07-29 12:29:38 +03:00
Pere Lev
d2ff048b2e
Tools for type-level-property-powered ForgeFed parsing-serializing 2024-07-18 22:30:34 +03:00
Pere Lev
b9ab5e546a
Upgrade to LTS 18 (last LTS with GHC 8)
The major changes:

- No more hit and hit-* packages
- No more diagram and SVG font stuff
- Dependency on darcs is not yet removed
- No more persistent-graph i.e. recursive SQL queries
- Some hit-network stuff still in use, now part of Vervis itself
- Git operations use the git command-line program, a convenient API is provided
  in Data.Git.Local
- No more patch parsing and no diff view, patches are treated as a piece of
  text and displayed as-is (although I could add syntax-highlighting as a nice
  touch for the HTML view)
2024-07-18 13:57:41 +03:00
Pere Lev
a5699898c5
Docs: Start API.md documentation file 2024-07-04 19:45:10 +03:00
Pere Lev
5c6e73a3d4
UI: Deck, Group, Project: Enhance collaborators view, prepare to add teams 2024-05-16 15:19:01 +03:00
Pere Lev
a428bd74ab
UI, S2S: Store errors in Errbox + display in notifications 2024-04-28 00:31:48 +03:00
Pere Lev
b47941af97
DB: Split migration model module + remove DestUsGatherTo* entities 2024-04-14 15:06:50 +03:00
Pere Lev
e2462627a5
Remove old empty Vervis.Federation.Collab module 2023-12-07 18:22:51 +02:00
Pere Lev
1a3a46b6b2
Implement OCAP "Verifying an invocation" process from ForgeFed spec
Vervis currently supports only direct grants. The new process supports
delegation chains as well. This commit just implements the new process
as a new function, without yet using it anywhere. The next commits will
plug it into Deck actor handlers.
2023-11-07 10:51:42 +02:00
Pere Lev
372fd35f2c
Project routes, handlers and creation UI 2023-06-26 22:02:54 +03:00
Pere Lev
581838e550
Support the 6 ForgeFed roles + launch repo/deck/loom actor upon creation 2023-06-17 21:35:00 +03:00
Pere Lev
29904080df
Clearly specify license as AGPL-3-or-later in cabal file 2023-06-16 17:14:40 +03:00
Pere Lev
a683185918
Actor system: Add support for C2S actor methods 2023-06-15 20:23:50 +03:00
Pere Lev
85f77fcac4
Deck: Port Invite handler 2023-06-08 15:38:09 +03:00
Pere Lev
9955a3c0ad
Deck: Port/write Accept, Reject, Follow, Undo 2023-06-07 10:15:30 +03:00
Pere Lev
e8e587af26
Generate FEP-8b32 authenticity proofs when delivering activities
Limitations:

- Verification of proofs not implemeneted yet, just generation.
  Verification probably coming in the next commit.
- Only jcs-eddsa-2022 is supported. Can add more cryptosuites once
  they're updated for the requirements of the VC Data Integrity spec.
- Bug: The proofs aren't stored in the DB versions of outgoing activities, i.e.
  HTTP GETing an activity won't include the proof. Probably not urgent
  to fix. Ideally, change the whole PersistJSONObject/Envelope/etc.
  thing to allow to serialize the activity exactly once.
2023-05-30 09:48:21 +03:00
Pere Lev
906b5e8f44
Update docs for darcs->git switch, and switch from darcs-rev to gitrev 2023-05-25 13:55:56 +03:00
fr33domlover
6786e2e0e1 Implement theater-based remote delivery and port personGrant 2023-05-24 22:17:14 +00:00
fr33domlover
c9db823c8c Implement actor-model system and start moving Person actor to it
This patch makes Vervis temporarily unusable, because all actors' inbox POST
handlers use the new system, but the actual federation handler code hasn't been
ported. The next patches will port all the S2S activities supported so far, as
well as C2S.
2023-04-29 10:40:44 +00:00
fr33domlover
756c2952f2 S2S: Re-implement and re-enable personFollowF 2022-10-25 18:02:06 +00:00
fr33domlover
8f8354ea5e C2S: Re-implement and enable resolveC, followC, undoC 2022-10-25 04:54:56 +00:00
fr33domlover
eb342b47ed DB: Move new entity declarations to a new module Vervis.Migration.Entities 2022-10-19 09:06:38 +00:00
fr33domlover
118b787416 UI: New ticket/MR creation form + deck/loom navigation links 2022-10-17 15:08:00 +00:00
fr33domlover
71bceec18b C2S, S2S: Re-enable createNoteC and personCreateNoteF 2022-10-16 11:26:24 +00:00
fr33domlover
32c87e3839 Improve the AP async HTTP delivery API and per-actor key support
New iteration of the ActivityPub delivery implementation and interface.
Advantages over previous interface:

* When sending a ByteString body, the sender is explicitly passed as a
  parameter instead of JSON-parsing it out of the ByteString
* Clear 3 operations provided: Send, Resend and Forward
* Support for per-actor keys
* Actor-type-specific functions (e.g. deliverRemoteDB_D) removed
* Only the most high-level API is exposed to Activity handler code, making
  handler code more concise and clear

Also added in this patch:

* Foundation for per-actor key support
* 1 key per actor allowed in DB
* Disabled C2S and S2S handlers now un-exported for clarity
* Audience and capability parsing automatically done for all C2S handlers
* Audience and activity composition automatically done for Vervis.Client
  builder functions

Caveats:

* Actor documents still don't link to their per-actor keys; that should be the
  last piece to complete per-actor key support
* No moderation and anti-spam tools yet
* Delivery API doesn't yet have good integration of persistence layer, e.g.
  activity is separately encoded into bytestring for DB and for HTTP; this will
  be improved in the next iteration
* Periodic delivery now done in 3 separate steps, running sequentially; it
  simplifies the code, but may be changed for efficiency/robustness in the next
  iterations
* Periodic delivery collects per-actor keys in a
  1-DB-transaction-for-each-delivery fashion, rather than grabbing them in the
  big Esqueleto query (or keeping the signed output in the DB; this isn't done
  currently to allow for smooth actor key renewal)
* No support yet in the API for delivery where the actor key has already been
  fetched, rather than doing a DB transaction to grab it; such support would be
  just an optimization, so it's low-priority, but will be added in later
  iterations
2022-10-12 16:50:11 +00:00
fr33domlover
323de5b114 UI, Doc: Update Vervis repo links, because the route structure changed 2022-09-27 04:49:17 +00:00
fr33domlover
cc9facdf5a UI: Tweak and re-enable UI for uploading personal SSH keys 2022-09-26 12:51:06 +00:00
fr33domlover
ba6f22b94b S2S: Implement loomApplyF (remote person asking to apply bundle on local loom) 2022-09-24 15:46:02 +00:00
fr33domlover
be95f15b21 C2S: Implement applyC (apply a patch/MR to a repo/branch)
Both Git and Darcs are supported

- Darcs implementation applies right on the bare repo, I haven't tested to make
  sure it works right (federated MR demo is going to be only for Git)
- Git implementation clones to temporary repo, runs `git am` on it to apply,
  then pushes to the real bare repo (because `git am` doesn't work on bare
  repos; I haven't tested yet to see how it handles conflicts; cloning and
  pushing should be efficient since the refs are just hardlinked rather than
  copied)
2022-09-24 09:04:10 +00:00
fr33domlover
b5adfce971 S2S: loomOfferTicketF, open MR sent by remote author 2022-09-23 15:59:21 +00:00
fr33domlover
ef8e1c1108 S2S: deckOfferTicketF (i.e. local deck receives ticket from remote author) 2022-09-23 15:58:54 +00:00
fr33domlover
de51fb9ab5 C2S: offerTicketC: If origin provided but not bundle, generate patches from git
For now it's implemented only for Git:

If tracker is a local loom, and a (local or remote) origin repo is specified,
but no patches are provided, then generate them ourselves!

* Clone the (local) target repo
* Add the (local or remote) origin repo as a git remote
* Make sure target branch is an ancestor of the origin branch
* Generate patches for the commits that origin adds on top of target
* Insert them into our DB
2022-09-22 17:12:37 +00:00
fr33domlover
de2e29d505 C2S: offerTicketC re-enabled and supporting looms and remote origin repo
What's missing:

- Match patch VCS, origin repo VCS and target repo VCS
- Hook into postPersonInboxR
- If only origin is provided, generate patches / otherwise somehow remember the
  commits proposed
2022-09-21 12:50:26 +00:00
fr33domlover
dae8554a12 UI: getPatchR: Display diff-syntax-highlighted patch content file 2022-09-19 11:00:47 +00:00
fr33domlover
1db56ced39 UI: Re-enable ticket page, some pieces still missing, mostly buttons 2022-09-17 17:42:04 +00:00
fr33domlover
e69d775f3f UI: Fix and re-enable deck ticket list view 2022-09-17 10:14:27 +00:00
fr33domlover
91cdbf51ab UI: Fix and re-enable getRepoCommitR 2022-09-16 11:41:58 +00:00
fr33domlover
e78f043f49 C2S & UI: Allow creation of a new Repo 2022-09-16 10:34:44 +00:00
fr33domlover
8ec98e2a59 S2S: Invite->Accept->Grant (for Repo, Deck, Loom and Person, not for Group)
Person inbox handler:
    - Invite: Parse and insert to inbox
    - Grant: Parse and insert to inbox

Repo/Deck/Loom inbox handler:
    - Invite: Parse and remember as Collab record in DB for later
    - Accept: Send a Grant (and remember it in DB)

Along with inviteC and acceptC, the Invite->Accept->Grant flow is now fully
federated, yay!

What's missing is UI for actually using it. Coming soon.
2022-09-08 12:00:14 +00:00
fr33domlover
43a1bb5ef7 vervis.cabal: Specify license as AGPL-3 because that's the release license 2022-09-06 15:38:34 +00:00
fr33domlover
9dddc7d846 S2S: Prepare inbox handlers for Repo, Deck and Loom 2022-09-06 10:52:14 +00:00
fr33domlover
ac867e56f2 S2S: Switch from Grant->Accept->Enable to Invite->Accept->Grant
Giving access now starts with an Invite activity, followed by Accept from the
Invite's recipient. Finally, the resource sends a Grant, which is the actual
OCap.
2022-09-05 16:19:52 +00:00
fr33domlover
c5bc60d9fa Expose only required modules of vervis:library in vervis.cabal
Only Vervis.Hook (for the hook programs) and Vervis.Application (for the web
app program itself) are exposed now. I suppose more will be needed for tests.
But now there's a clear distinction what's used by other components and what
isn't.
2022-09-01 09:34:25 +00:00
fr33domlover
bf0790b4e4 Update format of AUTHORS file, link to Fedi accounts instead of email 2022-09-01 09:28:38 +00:00
fr33domlover
dd0bdaa742 S2S: Implement preparation and generic steps in person inbox post handler
The steps are:

- Parse activity ID and match with the authenticated sender
- For local activity (we got via forwarding), find in DB
- For remote activity, cache in DB
- Insert activity to recipient's inbox

What's not there yet is the actual logic of handling specific activities.
2022-08-31 13:01:04 +00:00
fr33domlover
26ec6527e2 Client, UI: Form for creating a new Deck 2022-08-16 13:17:26 +00:00
fr33domlover
2e72684fd5 Switch to new actor layout
This is such a huge patch, it's probably impossible to tell what it does by
looking at the code. One thing is clear: It changes *everything* :P so here's
an overview:

- There are now 5 types of actors, each having its own top-level route
- So projects, repos, etc. are no longer "under" sharers
- Actor routes are now based on their KeyHashid, there are no "idents" anymore,
  i.e. URLs look random and don't contain user or repo names
- No sharers anymore; people and groups are distinct entities not sharing a
  common namespace or anything like that
- Project has been renamed to Deck and it simply means a ticket tracker; repos
  are no longer "under" projects
- In addition to Person, Group, Repo and Deck, there's a new actor type Loom,
  which is a patch tracker; i.e. Repo actors don't manage MRs anymore
- All C2S and S2S is temporarily disabled, because huge changes to the whole
  code are required and I'll do them gradually in the next patches
- Since form-based actions are implemented using C2S, they're disabled as well,
  so Vervis is now essentially read-only
- Some views have been temporarily removed, e.g. repo history and commit view
- A huge set of DB migrations has been added to adapt the DB to these changes;
  I haven't tested them yet on a read DB so there may be errors there; I'll fix
  them in the next patches if I find any (probably going to test on the main
  instance where Vervis itself is hosted...)
- Some modules got tech upgrades, e.g. LocalActor became a higher-kinded type
  and a similar pattern is probably relevant for several other types
- There's an 'Actor' entity in the DB schema now, and all 5 actor types use it
  for common things like inbox and outbox
- Although inbox and outbox are used only by Actor, so essentially could be
  removed, I haven't removed them; that's because I wonder if at some point
  users can have a tree of inboxes much like in email; I don't have an excuse
  for Outbox, but anyway, leaving them as is for now
- Workflows, roles and collaborators are partially removed/unused until I
  figure out a sane federated way to provide these features
- Since repo routes don't contain a "sharer" anymore, SSH URIs are now simpler,
  they already look like user@host/repo regardless of who "controls" that repo
2022-08-15 13:57:42 +00:00
fr33domlover
656e7a98b9 Changing main instance domain again 2022-06-27 20:21:05 +00:00
fr33domlover
a6e4587281 Raise build-time error on incomplete patterns
I realized I never intend to leave patterns (e.g. pattern matching in a 'case'
clause) incomplete, i.e. some cases left missing. When I do that it means I
forgot, and I'd like GHC to highlight it by raising an error instead of just
warning. Vervis has lots of warnings so it's hard to detect among them.

I suppose in other kinds of software people sometimes leave incomplete patterns
intentionally / are okay with a runtime exception being thrown? In a web
application, I definitely want to handle all cases, and be in control of how
errors are handled and displayed in UI.
2022-06-26 13:54:37 +00:00
fr33domlover
c3ff3c40eb S2S: repoApplyF, for now only on remotely hosted patches 2022-06-23 09:09:02 +00:00