* fixed invalid json examples
* correct type: integer for a count, not number
* correct type: array of string, not string
* add square brackets around entity return type
* added missing path parameter definition
* spacing fix
* PR comment: add link
* Update to libraries page following full review
Signed-off-by: Andy Piper <andypiper@users.noreply.github.com>
* Two additional libraries from issues
Signed-off-by: Andy Piper <andypiper@users.noreply.github.com>
---------
Signed-off-by: Andy Piper <andypiper@users.noreply.github.com>
* clarify effects of suspending users and server
There's a lot of confusion about how suspending affects existing follow relationships and some moderators assume the follow relationships will be restored when a remote account (or entire server) is un-suspended within the 30-day time window
* Correction of docs about server suspension
Co-authored-by: Claire <claire.github-309c@sitedethib.com>
---------
Co-authored-by: Claire <claire.github-309c@sitedethib.com>
The v2 endpoint incorrectly said it returned a v1 instance (though it linked to the correct entity) and the v1 endpoint incorrectly linked to the v2 entity (the text correctly said v1)
The current rbenv is 3.0.6 - I received an error when following these steps which said the expected version is 3.0.6. After updating to 3.0.6, the installation was successful.
* Convert left over Markdown figures to Hugo
Also add captions for the respective figures: profile.jpg, bell.jpg, and lists.jpg
* Convert another left over Markdown figure to Hugo
Also add a caption for the figure: bot-flag.jpg
This documentation has I believe one very confusing point: It uses two times `YOUR_S3_HOSTNAME` in the nginx configuration example, however the second time it looks like you actually have to use `YOUR_BUCKET_NAME.YOUR_S3_HOSTNAME`.
## Explanation
Mastodon is using path-style requests to S3 which looks like this:
https://s3.region-code.amazonaws.com/bucket-name/key-name
Once you enable the new virtual host nginx file using the current indications, the path-style request which goes to amazon looks like this:
https://s3.region-code.amazonaws.com/key-name
In other words, the bucket name is not being sent S3 and the images break.
This is because the current instructions make it seem like the header Host name is not including the bucket
`proxy_set_header Host YOUR_S3_HOSTNAME;`
With the current path-style request integration, one must use the bucket name in the Host header for this to work, hence the proposed change to
`proxy_set_header Host YOUR_BUCKET_NAME.YOUR_S3_HOSTNAME;`
* Improve documentation for TRUSTED_PROXY_IP
The documentation previously only indicated that `localhost` was trusted, but it appears that all private networks are trusted by default. I believe this because:
- I'm running my web and streaming processes within Docker containers and running Nginx on the Docker host. I believe they communicate over a 172.16.0.0/12 network that Docker creates. I tried looking at logs a bit and it _seems_ like things are working correctly. But if anyone has suggestions on how to verify that my Mastodon processes are recording the correct client IP, please let me know! We could include that advice in this documentation.
- I looked at the source code a bit and it appears that both the streaming and web processes use localhost and the private network ranges. But this is really my first time looking at the Mastodon code and I don't even know Ruby, so please double check me!
- I believe the streaming processes uses Express JS. I believe it sets the trusted proxy IP [here](d11d15748c/streaming/index.js (L150)). Express documents the `loopback` and `uniquelocal` values [here](https://expressjs.com/en/guide/behind-proxies.html).
- I'm less certain about web. It looks like the env var is parsed [here](d11d15748c/config/environments/production.rb (L44-L45)). It looks like `trusted_proxies` will be unset if the env var is unset. And maybe that results in [this check](https://github.com/mastodon/mastodon/blob/main/config/initializers/trusted_proxies.rb) getting bypassed? But it looks like Action Dispatch does it's own check [here](https://api.rubyonrails.org/classes/ActionDispatch/RemoteIp.html)?
* Try to improve the phrasing
Specifically I tried to make it less likely that people would do the wrong thing if they're using Cloudflare or a similar proxy service. It does seem pretty wordy now. I'm open to suggestions.
* Fix URLs to work when `baseURL` is in a sub-directory
* Use `RelPermalink` to not have assets loaded from `baseUrl`
* Add `.vercel` to gitignore
* Remove deploy Github Action, we are now using Vercel
* fix relrefs around trends and related entities
* revert moving caption-links to middle of page
* hide empty menu in table of contents
* clarify edit notifs are only for boosted statuses
* following/followers no longer need auth
* fix typo
* specify cooldown period for account Move
* use the correct cooldown
* add missing parameters to accounts/id/statuses
* link to account_statuses_filter.rb
* fix typo (#1072)
* fix typo (#1073)
* fix link to http sig spec (#1067)
* simply HTTP request examples in api methods docs
* add missing client_secret to oauth/token (#1062)
* Add any, all, none to hashtag timeline
* minor formatting changes
* Update signature requirements and advice
* fix public key -> private key
* clarify use of RSA with SHA256
* Add note about saving your profile after adding rel-me link
* v2 filters api
* comment out params that shouldn't be used in v2 filter api
* admin trends
* remove old todo
* canonical email blocks + scheduled statuses
* remove under-construction warnings from finished pages
* verify api method params with source code
* fix typo (#1088)
* fix broken caption-links (#1100)
* fix formatting of entities (#1094)
* Remove keybase section from user guide (#1093)
* fix typos (#1092)
* Verify limits are accurate (#1086)
* add mention of iframe limitation (#1084)
* Add CORS header to WEB_DOMAIN example (#1083)
* Fix typo (#1081)
* pin http sigs spec at draft 8
* Revert "pin http sigs spec at draft 8"
This reverts commit 9fd5f7032b.
* add case sensitivity warning to 4.0 roles
* Add url length note to bio (#1087)
* remove follow scope from examples (#1103)
* clarify usage of update_credentials to update profile fields
* add noindex to Account entitity
* remove required hint from technically not required property
I'm guessing there was meant to be text there, so I added some to explain how to do it
Co-authored-by: Alex_Sour <52638772+Alex-Sour@users.noreply.github.com>
`yarn set version stable` yields many install errors of Javascript packages. note https://codesti.com/issue/mastodon/documentation/931.
Setting `yarn set version classic` works around these problems and the rest of the instructions work as indicated. `classic` appears to be required.
The configuration is basically the same as with IPv4, but with some minor changes to make them work in IPv6.
Is it perfect? Probably not. But it's better than nothing.
Today I read the media/ api endpoint document and was confused about the axis orientation (IE is y up or down). I initially implemented an endpoint call with the wrong Y orientation.
There is a helpful diagram but I did not see it because I foolishly scrolled down, saw the return codes section, assumed that was the end of the document, and didn't scroll further.
Edit adds a reference from the arguments section at the top to the detailed explanation of "focus" at the bottom of the page, so the next fool doesn't make the mistake I did.
- Update `openjdk-17-jre-headless` in Ubuntu 20.04 and Debian 11
- Update ElasticSearch to 7.x
- Add `systemctl daemon-reload` after installation
Tested and it's working fine.
- Ubuntu 18.04 will be EOL on April, 2022. So I make changes for installation document with Ubuntu 20.04 and Debian 11 support.
- Added PostgreSQL with latest version (PostgreSQL 14)
- [Yarn](https://yarnpkg.com/getting-started/install) is now a default package since Node.js 16.10, there's no need to install yarn classic.
- From Mastodon [3.5.0](https://github.com/mastodon/mastodon/releases/tag/v3.5.0), ruby 3.0.3 is recommend.
Tested in Ubuntu 20.04 and Debian 11, all works fine.
Some people asked whether they should be running the maintenance script after seeing a PgHero warning about duplicate indexes.
This change highlights that the warning is unrelated to database index corruption.
Brook Miles