| Age | Commit message (Collapse) | Author |
|---|
|
The project was rewritten from Elixir to Go, primarily because:
- I don't write Elixir anymore and don't want to maintain a project in a
language I no longer write
- I already write Go for other projects, including my day job, so it's
a safer bet for a project that I want to maintain long term
- Go allows me to build portable executables that will make it easier
for others to run farside on their own machines
The Go version of Farsside also has a built in task to fetch the latest
services{-full}.json file from the repo and ingest it, which makes
running a farside server a lot simpler.
It also automatically fetches the latest instance state from
https://farside.link unless configured as a primary farside node, which
will allow others to use farside without increasing traffic to all
instances that are queried by farside (just to the farside node itself).
|
|
Nitter has been gone for a while, so it's now excluded from tests
related to redirecting functionality. Since other instances occasionally
pop up still, it's being kept in Farside for now.
|
|
This removes the dependency on Redis for core app functionality. Rather
than using the key/value store provided by Redis, Farside now uses a
key/val store provided by [cubdb](https://github.com/lucaong/cubdb) for
identical functionality but without reliance on a non-Elixir service.
This solution was chosen instead of ets, because storing instance data
in memory leads to a period of broken functionality whenever the app
restarts and hasn't re-populated instance data yet. It was also chosen
instead of dets, because the documentation for dets was pretty hard to
understand at first glance.
Tests and the CI build were updated to reflect the removed dependency on
Redis.
New environment variable `FARSIDE_DATA_DIR` can be used to point to a
directory where the instance data can be stored by cubdb.
Co-authored-by: Jason Clark <mithereal@gmail.com>
|
|
Connection values (such as redis server port and the port to run farside
on) as well as the services json file to use can now be set via
environment variables:
FARSIDE_PORT sets the port for Farside to run on
FARSIDE_REDIS_PORT sets the redis server port for Farside to use
FARSIDE_SERVICES_JSON sets the services json file for Farside to use
This partially addresses the move towards de-listing Cloudflare
instances by default by allowing different services json files to be
used with different redis servers.
See #43
|
|
Farside now supports redirecting based on a provided link to a "parent"
service, if such a parent service is supported.
For example, a link such as:
farside.link/https://www.youtube.com/watch?v=dQw4w9WgXcQ
will now redirect to any of the available YouTube related frontends.
This works by matching against a mapping of "parent" service domains
("youtube.com", "reddit.com", etc) to a list of their respective frontend
alternatives (["invidious", "piped"], ["libreddit", "teddit"], etc). A
random element is chosen from this list, and the remainder of Farside's
routing logic proceeds as if the user had chosen the service directly to
begin with.
Closes #37
|
|
The "throttling" performed by Farside now redirects to the same instance
as before, rather than outright blocking the connection.
|
|
The dependency took a long time to compile, and was causing problems for
a user who was attempting to build the project.
Since it wasn't a strictly necessary dependency, and `jason` was already
included in the project, all instances of `poison` have been replaced
with `jason`.
The only additional code that this introduced was converting from
generic maps returned by `Jason.decode` into Service structs.
|
|
|
|
Tests the throttling feature from the previous commit
|
|
This introduces a way of throttling requests in a way that makes sense
for the purpose of the app. The app only supports redirecting to one
particular service when browsing, which would seldom be required more
than once per second for normal "human" browsing.
Without this, the service could easily be used to DOS multiple instances
at once. That being said, anyone concerned about someone DOS-ing
multiple instances at once should be aware that this would be trivial to
do with a simple bash script. This is simply a preventative measure to
hopefully deter people from trying to attack all public instances of
private frontends using farside.link.
Note that this throttling applies to all routes in the app, including
the homepage. This could be updated to exclude the homepage I guess,
but I'm not really sure what the use case would be for that.
|
|
Introduces a new db key "<service>-previous" to track which instance was
last selected for a particular service. This allows for filtering the
list of available instances to exclude the instance that was last
picked, to ensure a (slightly) more even distribution of traffic.
There's still the possiblity of the following scenario, however:
:service instances > 2
/:service request #1 -> instance #1
/:service request #2 -> instance #2
/:service request #3 -> instance #1
/:service request #4 -> instance #2
where there are many ignored instances for a particular service. One
possible solution would be to implement the "<service>-previous" value
to be a list, rather than a single value, and push to that list until
only one element is left in the original "instance" array after
filtering, and then delete the "<service>-previous" key.
|
|
Updates testing to iterate through all available services and validate
that each one correctly produces a 302 redirect.
|
|
The name of the project is being refactored from Privacy Revolver to
Farside. The reasoning behind this is:
1. A shorter name is easier to remember
2. It can stand for "FOSS alternative redirecting service" (which I know
doesn't encapsulate all letters from "farside", but it's close enough).
This commit also includes improvements to the update script for
determining how far along the script is.
|
|
Obviously going to be expanded upon by quite a bit, but just wanted to
get started with basic testing sooner rather than later.
|
|
Rather than use a full blown framework*, adding basic routing with
Plug.Router seems to make more sense, since I'm not planning on hosting
any content through this app. The app itself will just be endpoints for
all available services that redirect the user to an available instance
for the requested service.
Note that I might change my mind about this, but that's unlikely. At
most there would just be a home page with info about available
instances, but even then that seems kinda pointless. Trying to keep this
as absolutely simple as possible.
*like Phoenix
|
