farside - Farside fork

Age	Commit message (Collapse)	Author
2025-01-21	Rewrite project, add daily update of services list	Ben Busby
	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).
2024-01-09	Extract remote ip from `X-Forwarded-For`	Ben Busby
	The remote IP returned in plug.conn is meant to be overwritten by the developer, and doesn't reflect the origin of the request based on headers. A new dependency has been added to make this change quicker to roll out.
2023-03-22	Allow compiling to standalone binary via bakeware	Ben Busby
	This introduces a simple way of compiling Farside to a somewhat portable, standalone binary. The resulting binary isn't completely portable since it depends on the C runtime of the host system. As a result, it's advised to use systems with older library versions when compiling for true portability. Closes #50 Co-authored-by: Jason Clark <mithereal@gmail.com>
2022-10-31	Remove Redis dep, replace w/ native Elixir lib	Ben Busby
	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>
2022-02-14	Replace `poison` dependency w/ `jason`	Ben Busby
	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.
2021-11-24	Use quantum core for update scheduling	Ben Busby
	Rather than requiring a traditional crontab install, the app now leverages quantum-core (link below) to schedule the instance update/sync task every 5 minutes. Some updates as a result: - The new job is scheduled at runtime in server.ex. - The update.exs script was refactored to be compiled along with the rest of the app as instances.ex. - Scheduler and Server modules were added for creating and executing the new update task - All shell scripts were removed, as they are no longer needed https://github.com/quantum-elixir/quantum-core
2021-11-12	Fix formatting	Ben Busby

2021-11-12	Throttle incoming requests to 1/sec per ip	Ben Busby
	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.
2021-11-07	Refactor project to new name	Ben Busby
	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.
2021-10-26	Add basic router test	Ben Busby
	Obviously going to be expanded upon by quite a bit, but just wanted to get started with basic testing sooner rather than later.
2021-10-22	Setup basic Plug.Router framework for serving requests	Ben Busby
	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
2021-10-22	Output available instances and fallback URL to redis	Ben Busby
	Once a list of available URLs has been determined for a particular service, the list is written as "service -> [list of instances]" to a local redis connection. These can then be used in the greater routing logic to pick a random instance from the list, or use a fallback instance if none are determined to be available.
2021-10-21	Validate status code for all service instances	Ben Busby
	Updated to filter out all instances that either time out (I believe default timeout for HTTPoison is 5s) or return a non-200 status code.
2021-10-21	Initialize update script	Ben Busby
	My initial thought for this: create a simple redis db for storing key value pairs of instance -> list of live instances for each privacy front end (libreddit, bibliogram, etc). A script executed on a certain schedule would (in the background) check each instance to make sure it isn't down or unreasonably slow. If the instance is available, add it to a list of available instances in the db. When a user navigates to the revolver url (something like <url>/<service>/<...>), the app would pick a random value from the list returned by redis.get('<service>') and forward the user to that instance. As a side note, this could instead load the instances json from a remote source (like github or something) so that changes to instances don't need to involve a redeploy of the entire app.