JoshuaCWebDeveloper
commented
1 year ago I vote against number 2. We should move away from maintaining a fork of pleroma, as it presents extra work which is unnecessary, imo.
If 1) succeeds, and is the only change we needed to Pleroma, then we can switch to using Pleroma directly without involving a fork.
Otherwise, we should create a new project that uses Pleroma as a dependency and makes any necessary changes we need, i.e. an option 3.
to make for a better relay experience, we currently have a fork of pleroma that fetches some history every time a box follows another box. The changes are pretty minimal, but do to the fact that we were originally forking the repo wholesale, we've diverged from main substantially.
As we'd like to keep parity with the main pleroma project, we should do some housekeeping here.
Two options:
1 (preferred) submit our changes to pleroma as a PR and get them accepted. The substantive change is something that used to be in pleroma but was removed after running into infinite recursion. Our implementation is constrained in scope so as to remove this problem.
2 rebase against pleroma master branch, keeping only the 20ish lines of code we need, and periodically merge upstream changes.