mirror of
https://github.com/superseriousbusiness/gotosocial
synced 2024-12-03 17:49:19 +00:00
[docs] Textual updates on markdown files (#756)
* A few spelling and grammer fixes on readme Changes a few wording, some punctuation and grammar. * Grammar and punctuation on Roadmap Mostly grammar and punctuation on the roadmap * Update README.md Restore British English spelling of favourite, because it's used on the API endpoints in Roadmap as well. * Grammar and punctuation on Contributing Mainly grammar and punctuation on Contributing file.
This commit is contained in:
parent
586ebb5059
commit
2ca234f42e
3 changed files with 58 additions and 58 deletions
|
@ -2,7 +2,7 @@
|
|||
|
||||
Hey! Welcome to the CONTRIBUTING.md for GoToSocial :) Thanks for taking a look, that kicks ass.
|
||||
|
||||
This document will expand as the project expands, so for now this is basically a stub.
|
||||
This document will expand as the project expands, so for now, this is basically a stub.
|
||||
|
||||
Contributions are welcome at this point, since the API is fairly stable now and the structure is somewhat coherent.
|
||||
|
||||
|
@ -80,7 +80,7 @@ To recompile bundles:
|
|||
BUDO_BUILD=1 node web/source
|
||||
```
|
||||
|
||||
Or you can run livereloading in development. It will start a webserver (ip/port printed in console, default localhost:8081), while also keeping the bundles
|
||||
Or you can run live reloading in development. It will start a webserver (ip/port printed in console, default localhost:8081), while also keeping the bundles
|
||||
up-to-date on disk. You can access the user/admin panels at localhost:8080/user, localhost:8080/admin, or run in tandem with the GoToSocial testrig, which will also
|
||||
serve the updated bundles from disk.
|
||||
|
||||
|
@ -96,7 +96,7 @@ Let's say you fork GoToSocial to `github.com/yourgithubname/gotosocial`, and the
|
|||
|
||||
The correct solution to this is to fork, then clone the upstream repository, then set `origin` of the upstream repository to that of your fork.
|
||||
|
||||
See [this blogpost](https://blog.sgmansfield.com/2016/06/working-with-forks-in-go/) for more details.
|
||||
See [this blog post](https://blog.sgmansfield.com/2016/06/working-with-forks-in-go/) for more details.
|
||||
|
||||
In case this post disappears, here are the steps (slightly modified):
|
||||
|
||||
|
@ -105,7 +105,7 @@ In case this post disappears, here are the steps (slightly modified):
|
|||
>
|
||||
> `go get github.com/superseriousbusiness/gotosocial`
|
||||
>
|
||||
> Fork the repository on Github or set up whatever other remote git repo you will be using. In this case, I would go to Github and fork the repository.
|
||||
> Fork the repository on GitHub or set up whatever other remote git repo you will be using. In this case, I would go to GitHub and fork the repository.
|
||||
>
|
||||
> Navigate to the top level of the repository on your computer. Note that this might not be the specific package you’re using:
|
||||
>
|
||||
|
@ -122,9 +122,9 @@ In case this post disappears, here are the steps (slightly modified):
|
|||
|
||||
## Setting up your test environment
|
||||
|
||||
GoToSocial provides a [testrig](https://github.com/superseriousbusiness/gotosocial/tree/main/testrig) with a bunch of mock packages you can use in integration tests.
|
||||
GoToSocial provides a [testrig](https://github.com/superseriousbusiness/gotosocial/tree/main/testrig) with a number of mock packages you can use in integration tests.
|
||||
|
||||
One thing that *isn't* mocked is the Database interface, because it's just easier to use an in-memory SQLite database than to mock everything out.
|
||||
One thing that *isn't* mocked is the Database interface because it's just easier to use an in-memory SQLite database than to mock everything out.
|
||||
|
||||
### Standalone Testrig with Pinafore
|
||||
|
||||
|
@ -154,7 +154,7 @@ Note the following constraints:
|
|||
|
||||
- Since the testrig uses an in-memory database, the database will be destroyed when the testrig is stopped.
|
||||
- If you stop the testrig and start it again, any tokens or applications you created during your tests will also be removed. As such, you need to log out and in again every time you stop/start the rig.
|
||||
- The testrig does not make any actual external http calls, so federation will not work from a testrig.
|
||||
- The testrig does not make any actual external HTTP calls, so federation will not work from a testrig.
|
||||
|
||||
### Running automated tests
|
||||
|
||||
|
@ -162,7 +162,7 @@ There are a few different ways of running tests. Each requires the use of the `-
|
|||
|
||||
#### SQLite
|
||||
|
||||
If you want to run tests as quickly as possible, using an SQLite in-memory database, use:
|
||||
If you would like to run tests as quickly as possible, using an SQLite in-memory database, use:
|
||||
|
||||
```bash
|
||||
GTS_DB_TYPE="sqlite" GTS_DB_ADDRESS=":memory:" go test ./...
|
||||
|
@ -194,7 +194,7 @@ Although these tests *are* part of the CI/CD testing process, you probably won't
|
|||
|
||||
## Project Structure
|
||||
|
||||
For project structure, GoToSocial follows a standard and widely-accepted project layout [defined here](https://github.com/golang-standards/project-layout). As the author writes:
|
||||
For project structure, GoToSocial follows a standard and widely accepted project layout [defined here](https://github.com/golang-standards/project-layout). As the author writes:
|
||||
|
||||
> This is a basic layout for Go application projects. It's not an official standard defined by the core Go dev team; however, it is a set of common historical and emerging project layout patterns in the Go ecosystem.
|
||||
|
||||
|
@ -233,7 +233,7 @@ Then, you can run the linter with:
|
|||
golangci-lint run
|
||||
```
|
||||
|
||||
If there's no output, great! It passed :)
|
||||
If there's no output, great! It passed :).
|
||||
|
||||
## Updating Swagger docs
|
||||
|
||||
|
@ -251,13 +251,13 @@ swagger generate spec -o docs/api/swagger.yaml --scan-models
|
|||
|
||||
GoToSocial uses [Drone](https://www.drone.io/) for CI/CD tasks like running tests, linting, and building Docker containers.
|
||||
|
||||
These runs are integrated with Github, and will be run on opening a pull request or merging into main.
|
||||
These runs are integrated with GitHub, and will be run on opening a pull request or merging into main.
|
||||
|
||||
The Drone instance for GoToSocial is [here](https://drone.superseriousbusiness.org/superseriousbusiness/gotosocial).
|
||||
|
||||
The `drone.yml` file is [here](./.drone.yml) -- this defines how and when Drone should run. Documentation for Drone is [here](https://docs.drone.io/).
|
||||
The `drone.yml` file is [here](./.drone.yml) — this defines how and when Drone should run. Documentation for Drone is [here](https://docs.drone.io/).
|
||||
|
||||
Please note that the `drone.yml` file must be signed by the Drone admin account in order to be considered valid. This must be done every time the file is changed. This is to prevent tampering and hijacking of the Drone instance. See [here](https://docs.drone.io/signature/).
|
||||
It is worth noting that the `drone.yml` file must be signed by the Drone admin account to be considered valid. This must be done every time the file is changed. This is to prevent tampering and hijacking of the Drone instance. See [here](https://docs.drone.io/signature/).
|
||||
|
||||
To sign the file, first install and setup the [drone cli tool](https://docs.drone.io/cli/install/). Then, run:
|
||||
|
||||
|
@ -267,29 +267,29 @@ drone -t PUT_YOUR_DRONE_ADMIN_TOKEN_HERE -s https://drone.superseriousbusiness.o
|
|||
|
||||
## Release Checklist
|
||||
|
||||
First things first: If this is a security hot-fix, we'll probably rush thru this list, and make a prettier release a few days later.
|
||||
First things first: If this is a security hot-fix, we'll probably rush through this list, and make a prettier release a few days later.
|
||||
|
||||
Now, with that out of the way, here's our Checklist.
|
||||
|
||||
GoToSocial follows [Semantic Versioning](https://semver.org/).
|
||||
So our first concern on the Checklist is:
|
||||
|
||||
- what version are we releasing?
|
||||
- What version are we releasing?
|
||||
|
||||
Next we need to check:
|
||||
|
||||
- do the assets need to be rebuilt and committed to the repository.
|
||||
- do the swagger docs need to be rebuilt?
|
||||
- Do the assets have to be rebuilt and committed to the repository.
|
||||
- Do the swagger docs have to be rebuilt?
|
||||
|
||||
On the project management side:
|
||||
|
||||
- are there any issues that need to be moved to a different milestone?
|
||||
- are there any things on the [Roadmap](./ROADMAP.md) that can be ticked off?
|
||||
- Are there any issues that have to be moved to a different milestone?
|
||||
- Are there any things on the [Roadmap](./ROADMAP.md) that can be ticked off?
|
||||
|
||||
Once we're happy with our Checklist, we can create the tag, and push it.
|
||||
And the rest [is automation](./.drone.yml).
|
||||
|
||||
We can now head to github, and add some personality to the release notes.
|
||||
We can now head to GitHub, and add some personality to the release notes.
|
||||
Finally, we make announcements on the all our channels that the release is out!
|
||||
|
||||
### What if something goes wrong?
|
||||
|
@ -300,7 +300,7 @@ We release a buggy release, we forgot something something important.
|
|||
If the release is so bad that it's unusable or dangerous! to a great part of our user-base, we can pull.
|
||||
That is: Delete the tag.
|
||||
|
||||
Either way, once we've fixed the issue, we just start from the top of this list again. Version numbers are cheap. It's cheap to burn them.
|
||||
Either way, once we've resolved the issue, we just start from the top of this list again. Version numbers are cheap. It's cheap to burn them.
|
||||
|
||||
## Building Docker containers
|
||||
|
||||
|
@ -326,7 +326,7 @@ Finally, to create a snapshot build, do:
|
|||
goreleaser --rm-dist --snapshot
|
||||
```
|
||||
|
||||
If all goes according to plan, you should now have a bunch of multiple-architecture binaries and tars inside the `./dist` folder, and snapshot Docker images should be built (check your terminal output for version).
|
||||
If all goes according to plan, you should now have a number of multiple-architecture binaries and tars inside the `./dist` folder, and snapshot Docker images should be built (check your terminal output for version).
|
||||
|
||||
### Manually
|
||||
|
||||
|
@ -342,6 +342,6 @@ You don't need to install go-swagger, Node, or Yarn to build Docker images this
|
|||
|
||||
## Financial Compensation
|
||||
|
||||
Right now there's no structure in place for financial compensation for pull requests and code. This is simply because there's no money being made on the project apart from the very small weekly Liberapay donations.
|
||||
Right now, there's no structure in place for financial compensation for pull requests and code. This is simply because there's no money being made on the project, apart from the very small weekly Liberapay donations.
|
||||
|
||||
If money starts coming in, I'll start looking at proper financial structures, but for now code is considered to be a donation in itself.
|
||||
If money starts coming in, I'll start looking at proper financial structures, but for now, code is considered to be a donation in itself.
|
||||
|
|
42
README.md
42
README.md
|
@ -57,7 +57,7 @@ If you've ever used something like Twitter or Tumblr (or even Myspace!) GoToSoci
|
|||
|
||||
**GoToSocial does NOT use algorithms or collect data about you to suggest content or 'improve your experience'**. The timeline is chronological: whatever you see at the top of your timeline is there because it's *just been posted*, not because it's been selected as interesting (or controversial) based on your personal profile.
|
||||
|
||||
GoToSocial is not designed for 'must-follow' influencers with tens of thousands of followers, and it's not designed to be addictive. Your timeline and your experience is shaped by who you follow and how you interact with people, not by metrics of engagement!
|
||||
GoToSocial is not designed for 'must-follow' influencers with tens of thousands of followers, and it's not designed to be addictive. Your timeline and your experience are shaped by who you follow and how you interact with people, not by metrics of engagement!
|
||||
|
||||
GoToSocial doesn't claim to be *better* than any other application, but it offers something that might be better *for you* in particular.
|
||||
|
||||
|
@ -67,7 +67,7 @@ Because GoToSocial uses [ActivityPub](https://activitypub.rocks/), you can hang
|
|||
|
||||
![the activitypub logo](docs/assets/ap_logo.svg)
|
||||
|
||||
Federation means that your home server is part of a network of servers all over the world that all communicate using the same protocol. Your data is no longer centralized on one company's servers, but resides on your own server and is shared -- as you see fit -- across a resilient web of servers run by other people.
|
||||
Federation means that your home server is part of a network of servers all over the world that all communicate using the same protocol. Your data is no longer centralized on one company's servers, but resides on your own server and is shared — as you see fit — across a resilient web of servers run by other people.
|
||||
|
||||
This federated approach also means that you aren't beholden to arbitrary rules from some gigantic corporation potentially thousands of miles away. Your server has its own rules and culture; your fellow server residents are your neighbors; you will likely get to know your server admins and moderators, or be an admin yourself.
|
||||
|
||||
|
@ -87,9 +87,9 @@ For a detailed view on what's implemented and what's not, and progress made towa
|
|||
|
||||
### Mastodon API compatibility
|
||||
|
||||
The Mastodon API has become the de-facto standard for client communication with federated servers, so GoToSocial has implemented and extended the API with custom functionality.
|
||||
The Mastodon API has become the de facto standard for client communication with federated servers, so GoToSocial has implemented and extended the API with custom functionality.
|
||||
|
||||
In short this means full support for modern, beautiful apps like [Tusky](https://tusky.app/) and [Pinafore](https://pinafore.social/).
|
||||
In short, this means full support for modern, beautiful apps like [Tusky](https://tusky.app/) and [Pinafore](https://pinafore.social/).
|
||||
|
||||
Tusky | Pinafore
|
||||
:-----------------------------------------------------------:|:------------------------------------------------------------------:
|
||||
|
@ -112,9 +112,9 @@ It also allows you to customize how people interact with your posts:
|
|||
|
||||
### Customizability for admins
|
||||
|
||||
Lots of [config options](./example/config.yaml) for admins to play around with, including:
|
||||
Plenty of [config options](./example/config.yaml) for admins to play around with, including:
|
||||
|
||||
- Easily-adjustable post length.
|
||||
- Easily adjustable post length.
|
||||
- Media upload size settings.
|
||||
|
||||
### Easy to run
|
||||
|
@ -125,9 +125,9 @@ GoToSocial plays nice with lower-powered machines like Raspberry Pi, old laptops
|
|||
|
||||
### Safety + security features
|
||||
|
||||
- Built-in, automatic support for secure HTTPS with [LetsEncrypt](https://letsencrypt.org/).
|
||||
- Built-in, automatic support for secure HTTPS with [Let's Encrypt](https://letsencrypt.org/).
|
||||
- Strict privacy enforcement for posts and strict blocking logic.
|
||||
- Import and export allowlists and denylists. Subscribe to community-created blocklists (think Adblocker, but for federation!).
|
||||
- Import and export allow lists and deny lists. Subscribe to community-created block lists (think Ad blocker, but for federation!).
|
||||
- HTTP signature authentication: GoToSocial requires [HTTP Signatures](https://tools.ietf.org/id/draft-cavage-http-signatures-01.html) when sending and receiving messages, to ensure that your messages can't be tampered with and your identity can't be forged.
|
||||
|
||||
### Various federation modes
|
||||
|
@ -135,16 +135,16 @@ GoToSocial plays nice with lower-powered machines like Raspberry Pi, old laptops
|
|||
GoToSocial doesn't apply a one-size-fits-all approach to federation. Who your server federates with should be up to you.
|
||||
|
||||
- 'Normal' federation; discover new servers.
|
||||
- Allowlist-only federation; choose which servers you talk to.
|
||||
- *Allow list*-only federation; choose which servers you talk to.
|
||||
- Zero federation; keep your server private.
|
||||
|
||||
### OIDC integration
|
||||
|
||||
GoToSocial supports [OpenID Connect (OIDC)](https://openid.net/connect/) identity providers, meaning you can integrate it with existing user management services like [Auth0](https://auth0.com/), [Gitlab](https://docs.gitlab.com/ee/integration/openid_connect_provider.html), etc, or run your own and hook GtS up to that (we recommend [Dex](https://dexidp.io/)).
|
||||
GoToSocial supports [OpenID Connect (OIDC)](https://openid.net/connect/) identity providers, meaning you can integrate it with existing user management services like [Auth0](https://auth0.com/), [Gitlab](https://docs.gitlab.com/ee/integration/openid_connect_provider.html), etc., or run your own and hook GtS up to that (we recommend [Dex](https://dexidp.io/)).
|
||||
|
||||
### Backend-first design
|
||||
|
||||
Unlike other federated server projects, GoToSocial doesn't include an integrated client front-end (ie., a webapp).
|
||||
Unlike other federated server projects, GoToSocial doesn't include an integrated client front-end (i.e., a web app).
|
||||
|
||||
Instead, like Matrix.org's [Synapse](https://github.com/matrix-org/synapse) project, it provides a relatively generic backend server implementation, some beautiful static pages for profiles and posts, and a [well-documented API](https://docs.gotosocial.org/en/latest/api/swagger/).
|
||||
|
||||
|
@ -156,7 +156,7 @@ These cool things will be implemented if time allows (because we really want the
|
|||
|
||||
- **Groups** and group posting!
|
||||
- Reputation-based 'slow' federation.
|
||||
- Community decision making for federation and moderation actions.
|
||||
- Community decision-making for federation and moderation actions.
|
||||
- User-selectable custom templates for rendering public posts:
|
||||
- Twitter-style
|
||||
- Blogpost
|
||||
|
@ -179,7 +179,7 @@ These packages are not maintained by GoToSocial, so please direct questions and
|
|||
|
||||
## Known Issues
|
||||
|
||||
Since GoToSocial is still in alpha, there are plenty of bugs. We use Github issues to track these. [Check them out here](https://github.com/superseriousbusiness/gotosocial/issues?q=is%3Aissue+is%3Aopen+label%3Abug).
|
||||
Since GoToSocial is still in alpha, there are plenty of bugs. We use GitHub issues to track these. [Check them out here](https://github.com/superseriousbusiness/gotosocial/issues?q=is%3Aissue+is%3Aopen+label%3Abug).
|
||||
|
||||
### Client App Issues
|
||||
|
||||
|
@ -187,11 +187,11 @@ GoToSocial works great with Tusky and Pinafore, but some other client applicatio
|
|||
|
||||
### Federation Issues
|
||||
|
||||
Since every ActivityPub server implementation has a slightly different interpretation of the protocol, some servers don't quite federate properly with GoToSocial yet. We're tracking these issues [in this project](https://github.com/superseriousbusiness/gotosocial/projects/4). Eventually we want to make sure that any implementation that can federate nicely with Mastodon should also be able to federate with GoToSocial.
|
||||
Since every ActivityPub server implementation has a slightly different interpretation of the protocol, some servers don't quite federate properly with GoToSocial yet. We're tracking these issues [in this project](https://github.com/superseriousbusiness/gotosocial/projects/4). Eventually, we want to make sure that any implementation that can federate nicely with Mastodon should also be able to federate with GoToSocial.
|
||||
|
||||
## Contributing
|
||||
|
||||
You wanna contribute to GtS? Great! ❤️❤️❤️ Check out the issues page to see if there's anything you wanna jump in on, and read the [CONTRIBUTING.md](./CONTRIBUTING.md) file for guidelines and setting up your dev environment.
|
||||
You would like to contribute to GtS? Great! ❤️❤️❤️ Check out the issues page to see if there's anything you intend to jump in on, and read the [CONTRIBUTING.md](./CONTRIBUTING.md) file for guidelines and setting up your dev environment.
|
||||
|
||||
## Contact
|
||||
|
||||
|
@ -211,12 +211,12 @@ The following libraries and frameworks are used by GoToSocial, with gratitude
|
|||
- [gin-gonic/gin](https://github.com/gin-gonic/gin); speedy router engine. [MIT License](https://spdx.org/licenses/MIT.html).
|
||||
- [gin-contrib/cors](https://github.com/gin-contrib/cors); Gin CORS middleware. [MIT License](https://spdx.org/licenses/MIT.html).
|
||||
- [gin-contrib/gzip](https://github.com/gin-contrib/gzip); Gin gzip middleware. [MIT License](https://spdx.org/licenses/MIT.html).
|
||||
- [gin-contrib/sessions](https://github.com/gin-contrib/sessions); Gin sessions middleware. [MIT License](https://spdx.org/licenses/MIT.html)
|
||||
- [gin-contrib/static](https://github.com/gin-contrib/static); Gin static page middleware. [MIT License](https://spdx.org/licenses/MIT.html)
|
||||
- [gin-contrib/sessions](https://github.com/gin-contrib/sessions); Gin sessions middleware. [MIT License](https://spdx.org/licenses/MIT.html).
|
||||
- [gin-contrib/static](https://github.com/gin-contrib/static); Gin static page middleware. [MIT License](https://spdx.org/licenses/MIT.html).
|
||||
- [go-fed/httpsig](https://github.com/go-fed/httpsig); secure HTTP signature library. [BSD-3-Clause License](https://spdx.org/licenses/BSD-3-Clause.html).
|
||||
- [google/uuid](https://github.com/google/uuid); UUID generation. [BSD-3-Clause License](https://spdx.org/licenses/BSD-3-Clause.html)
|
||||
- [google/uuid](https://github.com/google/uuid); UUID generation. [BSD-3-Clause License](https://spdx.org/licenses/BSD-3-Clause.html).
|
||||
- [google/wuffs](https://github.com/google/wuffs); png-stripping code. [Apache-2.0 License](https://spdx.org/licenses/Apache-2.0.html).
|
||||
- [go-playground/validator](https://github.com/go-playground/validator); struct validation. [MIT License](https://spdx.org/licenses/MIT.html)
|
||||
- [go-playground/validator](https://github.com/go-playground/validator); struct validation. [MIT License](https://spdx.org/licenses/MIT.html).
|
||||
- [gorilla/websocket](https://github.com/gorilla/websocket); Websocket connectivity. [BSD-2-Clause License](https://spdx.org/licenses/BSD-2-Clause.html).
|
||||
- [gruf/go-debug](https://codeberg.org/gruf/go-debug); profiling support in debug builds. [MIT License](https://spdx.org/licenses/MIT.html).
|
||||
- [gruf/go-kv](https://codeberg.org/gruf/go-kv); key-value field formatting. [MIT License](https://spdx.org/licenses/MIT.html).
|
||||
|
@ -243,7 +243,7 @@ The following libraries and frameworks are used by GoToSocial, with gratitude
|
|||
- [stretchr/testify](https://github.com/stretchr/testify); test framework. [MIT License](https://spdx.org/licenses/MIT.html).
|
||||
- [superseriousbusiness/exif-terminator](https://github.com/superseriousbusiness/exif-terminator); EXIF data removal. [GNU AGPL v3 LICENSE](https://spdx.org/licenses/AGPL-3.0-or-later.html).
|
||||
- [superseriousbusiness/activity](https://github.com/superseriousbusiness/activity) forked from [go-fed/activity](https://github.com/go-fed/activity); Golang ActivityPub/ActivityStreams library. [BSD-3-Clause License](https://spdx.org/licenses/BSD-3-Clause.html).
|
||||
- [superseriousbusiness/oauth2](https://github.com/superseriousbusiness/oauth2) forked from [go-oauth2/oauth2](https://github.com/go-oauth2/oauth2); oauth server framework and token handling. [MIT License](https://spdx.org/licenses/MIT.html).
|
||||
- [superseriousbusiness/oauth2](https://github.com/superseriousbusiness/oauth2) forked from [go-oauth2/oauth2](https://github.com/go-oauth2/oauth2); OAuth server framework and token handling. [MIT License](https://spdx.org/licenses/MIT.html).
|
||||
- [go-swagger/go-swagger](https://github.com/go-swagger/go-swagger); Swagger OpenAPI spec generation. [Apache-2.0 License](https://spdx.org/licenses/Apache-2.0.html).
|
||||
- [tdewolff/minify](https://github.com/tdewolff/minify); HTML minification for Markdown-submitted posts. [MIT License](https://spdx.org/licenses/MIT.html).
|
||||
- [uptrace/bun](https://github.com/uptrace/bun); database ORM. [BSD-2-Clause License](https://spdx.org/licenses/BSD-2-Clause.html).
|
||||
|
@ -263,7 +263,7 @@ In alphabetical order:
|
|||
|
||||
### Special Thanks
|
||||
|
||||
A huge thank you to CJ from [go-fed](https://github.com/go-fed/activity): without your work GoToSocial would not have been possible.
|
||||
A huge thank you to CJ from [go-fed](https://github.com/go-fed/activity): without your work, GoToSocial would not have been possible.
|
||||
|
||||
Thanks to everyone who has used GtS, opened an issue, suggested something, given funding, and otherwise encouraged or supported the project!
|
||||
|
||||
|
|
26
ROADMAP.md
26
ROADMAP.md
|
@ -19,7 +19,7 @@ All the dates contained in this document are best-guess only. It's useful to hav
|
|||
|
||||
## Beta Aims
|
||||
|
||||
The milestone for beta in GoToSocial's case is to have a feature set that roughly compares to existing popular ActivityPub server implementations (minus features which we don't see as particularly important or useful). The beta milestone also includes GoToSocial-specific features which we believe are vital for user safety, such as local-only posting, blocklist subscriptions, and so on.
|
||||
The milestone for beta in GoToSocial's case is to have a feature set that roughly compares to existing popular ActivityPub server implementations (minus features which we don't see as particularly important or useful). The beta milestone also includes GoToSocial-specific features which, we believe, are vital for user safety, such as local-only posting, block list subscriptions, and so on.
|
||||
|
||||
Once feature parity is roughly in place, we will use beta time to start adding and polishing bonus features like slow federation, group moderation decisions, migration tooling, etc.
|
||||
|
||||
|
@ -36,36 +36,36 @@ What follows is a per-quarter timeline of features that will be implemented on t
|
|||
|
||||
Each quarter contains one 'big feature' which will probably take the longest amount of time that quarter.
|
||||
|
||||
**This timeline is a best-guess about when things will be implemented. The order of feature releases may change. It may go faster or slower depending on the amount of hurdles we run into, and the amount of help we receive from community contribitions of code. The timeline also does not include background tasks like admin, polishing existing features, refactoring code, and ensuring compatibility with other AP implementations.**
|
||||
**This timeline is a best-guess about when things will be implemented. The order of feature releases may change. It may go faster or slower depending on the number of hurdles we run into, and the amount of help we receive from community contributions of code. The timeline also does not include background tasks like admin, polishing existing features, refactoring code, and ensuring compatibility with other AP implementations.**
|
||||
|
||||
### Q3 2022
|
||||
|
||||
- **Big Feature** -- User settings page: allow users to edit their profile page and settings through a web page served by the GtS instance, for cases where client apps don't implement their own settings page.
|
||||
- Blocklist subscription support: allow instance admins to subscribe their instance to plaintext domain blocklists (much of the work for this is already in place).
|
||||
- Block list subscription support: allow instance admins to subscribe their instance to plaintext domain block lists (much of the work for this is already in place).
|
||||
- Tag support: implement federating hashtags and viewing hashtags to allow users to discover posts that they might be interested in.
|
||||
|
||||
### Q4 2022
|
||||
|
||||
- **Big Feature** -- Video support: allow users to view + post videos (before we only implemented images and gifs).
|
||||
- **Big Feature** — Video support: allow users to view + post videos (before we only implemented images and gifs).
|
||||
- Custom emoji support: allow users to use custom emojis in posts. Fetch custom emojis from remote instances and display them properly.
|
||||
- Pinned posts: allow users to 'feature' or 'pin' posts on their profile, and serve these featured posts via AP for other servers to see.
|
||||
- Profile fields: allow users to set 'fields' on their profile: short key/value items that can display pronouns, links to websites, etc.
|
||||
|
||||
### Q1 2023
|
||||
|
||||
- **Big Feature** -- Reports: allow users to file reports for abusive behavior etc. Expose the API for admins to view + act on reports. Handle federation of reports.
|
||||
- List support: allow users to create lists of other users which they can view as separate timelines.
|
||||
- **Big Feature** — Reports: allow users to file reports for abusive behavior etc. Expose the API for admins to view + act on reports. Handle federation of reports.
|
||||
- List support: allow users to create lists of other users, which they can view as separate timelines.
|
||||
- Polls support: allow users to create polls and vote in existing polls; federate the polls correctly via AP.
|
||||
|
||||
### Q2 2023
|
||||
|
||||
- **Big Feature** -- Sign-up flow. Allow users to submit a sign up request to an instance. Allow admins to moderate sign-up requests.
|
||||
- **Big Feature** — Sign-up flow. Allow users to submit a sign-up request to an instance. Allow admins to moderate sign-up requests.
|
||||
- Direct conversations: Allow users to see all direct-message conversations they're a part of.
|
||||
- Muting conversations: Allow users to mute notifications for conversations they're no longer interested in.
|
||||
|
||||
### Q3 2023
|
||||
|
||||
- **Big Feature** -- Support the `Move` Activity, to allow users to move across instances and Fediverse implementations.
|
||||
- **Big Feature** — Support the `Move` Activity, to allow users to move across instances and Fediverse implementations.
|
||||
- More to be confirmed.
|
||||
|
||||
## Detailed To-do List
|
||||
|
@ -81,10 +81,10 @@ Crossed out - will not be implemented / will be stubbed only.
|
|||
- [x] /api/v1/apps POST (Create an application)
|
||||
- [ ] /api/v1/apps/verify_credentials GET (Verify an application works)
|
||||
- [x] /oauth/authorize GET (Show authorize page to user)
|
||||
- [x] /oauth/authorize POST (Get an oauth access code for an app/user)
|
||||
- [x] /oauth/authorize POST (Get an OAuth access code for an app/user)
|
||||
- [x] /oauth/token POST (Obtain a user-level access token)
|
||||
- [ ] /oauth/revoke POST (Revoke a user-level access token)
|
||||
- [x] /auth/sign_in GET (Show form for user signin)
|
||||
- [x] /auth/sign_in GET (Show form for user sign-in)
|
||||
- [x] /auth/sign_in POST (Validate username and password and sign user in)
|
||||
- [ ] Accounts
|
||||
- [x] /api/v1/accounts POST (Register a new account)
|
||||
|
@ -205,7 +205,7 @@ Crossed out - will not be implemented / will be stubbed only.
|
|||
- [x] /api/v1/admin/accounts/:id/action POST (Perform an admin action on account)
|
||||
- [ ] /api/v1/admin/accounts/:id/approve POST (Approve pending account)
|
||||
- [ ] /api/v1/admin/accounts/:id/reject POST (Deny pending account)
|
||||
- [ ] /api/v1/admin/accounts/:id/enable POST (Reenable a disabled account)
|
||||
- [ ] /api/v1/admin/accounts/:id/enable POST (Re-enable a disabled account)
|
||||
- [ ] /api/v1/admin/accounts/:id/unsilence POST (Unsilence a silenced account)
|
||||
- [ ] /api/v1/admin/accounts/:id/unsuspend POST (Unsuspend a suspended account)
|
||||
- [ ] /api/v1/admin/reports GET (View all reports)
|
||||
|
@ -255,7 +255,7 @@ Crossed out - will not be implemented / will be stubbed only.
|
|||
- [ ] Reputation scoring system for instances
|
||||
- [x] 'Greedy' federation
|
||||
- [ ] No federation (insulate this instance from the Fediverse)
|
||||
- [ ] Allowlist
|
||||
- [ ] Allow list
|
||||
- [x] Secure HTTP signatures (creation and validation)
|
||||
- [x] Storage
|
||||
- [x] Internal/statuses/preferences etc
|
||||
|
@ -270,7 +270,7 @@ Crossed out - will not be implemented / will be stubbed only.
|
|||
- [x] Authorization middleware
|
||||
- [ ] Rate limiting middleware
|
||||
- [ ] Scope middleware
|
||||
- [x] Permissions/acl middleware for admins+moderators
|
||||
- [x] Permissions/ACL middleware for admins+moderators
|
||||
- [ ] Documentation
|
||||
- [x] Swagger API documentation
|
||||
- [x] ReadTheDocs.io documentation
|
||||
|
|
Loading…
Reference in a new issue