2021-01-17 22:08:25 +00:00
|
|
|
# Things That Need To Be Done
|
|
|
|
|
|
|
|
## Actix Web 4.0
|
|
|
|
It's not out yet, and not everything has a beta release yet, but we should continue tracking the
|
|
|
|
status of 4.0 and update our libraries as we can.
|
|
|
|
|
|
|
|
## Async
|
|
|
|
A lot of logic in the Profiles and Submissions modules synchronously accesses Sled, which is an
|
|
|
|
issue because Sled is potentially blocking. All of the Big Dangers (transactions) are safely on a
|
|
|
|
threadpool already, but a couple iterations are currently occuring directly on the Arbiters.
|
|
|
|
|
|
|
|
## Organization
|
|
|
|
A lot of modules in hyaenidae-server have circular dependencies, and a few are more than a thousand
|
|
|
|
lines long, each. These should be separated where possible into smaller modules which create a
|
|
|
|
dependency DAG
|
|
|
|
|
|
|
|
## Record Caching
|
|
|
|
Although Sled itself has in-memory caching for data, anything that requires
|
|
|
|
serialization/deserialization should be read at most once when in a route. This can be done in a
|
|
|
|
manner similar to the FederationView in the admin module. We build HashMaps mapping object IDs to
|
|
|
|
the Objects, and construct Vecs of Object IDs to denote ordering of objects. The view then produces
|
|
|
|
iterators over references to Objects by iterating over the IDs and fetching objects from the
|
|
|
|
HashMap.
|
|
|
|
|
|
|
|
#### Example
|
|
|
|
```rust
|
|
|
|
struct SubmissionView<'a> {
|
|
|
|
author: &'a Profile,
|
|
|
|
submission: &'a Submission,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'a> SubmissionView<'a> {
|
|
|
|
fn whatever_method(&self) -> String {
|
|
|
|
...
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
struct ViewState {
|
|
|
|
profiles: HashMap<Uuid, Profile>,
|
|
|
|
submissions: HashMap<Uuid, Submission>,
|
|
|
|
ordered: Vec<Uuid>,
|
|
|
|
}
|
|
|
|
|
2021-01-17 22:15:51 +00:00
|
|
|
impl ViewState {
|
2021-01-17 22:08:25 +00:00
|
|
|
fn submissions<'a>(&'a self) -> impl Iterator<Item = SubmissionView<'a>> + 'a {
|
|
|
|
self.ordered.iter().filter_map(move |id| {
|
|
|
|
let submission = self.submissions.get(id)?;
|
|
|
|
let author = self.profiles.get(&submission.profile_id())?;
|
|
|
|
|
|
|
|
Some(SubmissionView { author, submission })
|
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
|
|
|
This pattern allows for each Object to be stored at most once during a route, and it also avoids
|
|
|
|
cloning when multiple submissions were posted by the same profile, for example.
|
|
|
|
|
|
|
|
## Tags
|
|
|
|
Tags are useful for searching Hyaenidae for content. There should be a tag system that makes it
|
|
|
|
simple to search for submissions.
|
|
|
|
|
|
|
|
Tasks:
|
|
|
|
- Design a Tag database optimized for multi-tag lookups (within reason)
|
|
|
|
- Design a UI for authors to add tags to a submission
|
|
|
|
- Design ActivityPub interop for tag federation
|
|
|
|
|
|
|
|
## Reports
|
|
|
|
Reports are implemented for on-server moderation, but cross-server moderation has not been tested.
|
|
|
|
|
|
|
|
Tasks:
|
|
|
|
- Add a "delete" mechanism for remote objects. This should not induce any federation, but should
|
|
|
|
ensure the object is not accessible locally
|
|
|
|
- Enable forwarding reports to origin server. There is already code written to perform this
|
|
|
|
forwarding, but it is not exposed in the UI.
|
|
|
|
|
|
|
|
## Reacts
|
|
|
|
Reacts are similar to "likes" on other platforms, but do not get added to a collection for a given
|
|
|
|
profile. Reacts only notify the author of the item being reacted to.
|
|
|
|
|
|
|
|
Tasks:
|
|
|
|
- Design a UI for reacting to submissions
|
|
|
|
- Design a UI for reacting to comments
|
|
|
|
- Design a UI for reacting to posts (see Posts)
|
|
|
|
- Decide which kinds of reacts are valid
|
|
|
|
|
|
|
|
## Posts
|
|
|
|
Posts are top-level content created by profiles that do not have associated images, and so cannot be
|
|
|
|
considered Submissions. Posts are stored and viewed separately from submissions, and are more
|
|
|
|
"ephemeral" in that they will not backfill (see Backfills).
|
|
|
|
|
|
|
|
Tasks:
|
|
|
|
- Design a Post database
|
|
|
|
- Design a UI for creating new posts
|
|
|
|
- Design a UI for viewing posts from followed accounts
|
|
|
|
- Hook Posts into Note federation code
|
|
|
|
|
|
|
|
## Direct Messages
|
|
|
|
Direct Messages are Posts that are shared directly between two profiles, and are not publically
|
|
|
|
visible to other profiles.
|
|
|
|
|
|
|
|
## Backfills
|
|
|
|
Bakfills for a given item should not be permitted to run concurrently. A single backfill task may be
|
|
|
|
permitted to have multiple requests in-flight, but no two tasks may backfill the same item. There
|
|
|
|
should also be a limit on concurrency for backfills from a given server
|
|
|
|
|
|
|
|
Tasks:
|
|
|
|
- Add Profile Backfill on federation
|
|
|
|
- Add Submission Backfill on follow
|
|
|
|
|
|
|
|
## Object Cleanup
|
|
|
|
When things get deleted or suspended, we need to ensure that the database does not hold onto any
|
|
|
|
lingering data. This includes cleaning text fields for deleted items, cleaning up dependent items on
|
|
|
|
deletion.
|
|
|
|
|
|
|
|
Tasks:
|
|
|
|
- Differentiate between Profile Deletion and Profile Suspsension
|
|
|
|
- Federate profile suspensions for local suspended profiles
|
|
|
|
- Delete profiles (and submissions and comments and reacts) for defederated servers
|
|
|
|
|
|
|
|
## Federation Fixes
|
|
|
|
Not all of federation has been tested yet
|
|
|
|
|
|
|
|
Things that have been tested:
|
|
|
|
- Federation:
|
|
|
|
- Request
|
|
|
|
- Accept
|
|
|
|
- Reject
|
|
|
|
- Defederate
|
|
|
|
- Profiles:
|
|
|
|
- Create
|
|
|
|
- Update
|
|
|
|
- Submissions:
|
|
|
|
- Create
|
|
|
|
- Update
|
|
|
|
|
|
|
|
Anything not in this list has not been tested and needs to be verified and possibly fixed.
|