* Fix font-weight for CJK fonts
* Use `font-weight: 700;` for mobile support
* Fix indentation
* Remove trailing whitespace
* Remove trailing whitespace
The specs for Settings::DeletesController include an example that
sets Settings.open_deletion to false and expects the "if deletion is not
available, redirect to root" logic to run. However, this spec does not
set up a user, which means that the spec (intentionally or otherwise)
expects this redirection to work with unauthenticated access.
We should preserve that behavior. To do so, we prepend the deletion
check to the action chain set up by Settings::BaseController, so that
said check occurs before the authenticate_user! check.
* Break out nested relationship API keys
This closes#5856 by restoring the existing behavior of the `muting`
and `following` keys (returning booleans rather than truthy or false).
It adds `showing_reblogs` and `muting_notifications` keys:
* `showing_reblogs` returns true if:
1. You've requested to follow the user, with reblogs shown, or
2. You are following the user, with reblogs shown.
* `muting_notifications` returns true if you have muted the user and
their notifications as well.
* Rubocop fix
* Fix pulling reblog/mute status from relationships
I could swear this had passed tests before, but apparently not.
Works now.
* More test fixes
Really, you'd expect this to be more straightforward.
* Add list of lists component to web UI
* Add list adding
* Add list removing
* List editor modal
* Add API account search limited by following=true relation
* Rework list editor modal
* Remove mandatory pagination of GET /api/v1/lists/:id/accounts
* Adjust search input placeholder
* Fix rspec (#5890)
* i18n: (zh-CN) Add missing translations for #5811 (#5891)
* i18n: (zh-CN) yarn manage:translations -- zh-CN
* i18n: (zh-CN) Add missing translations for #5811
* Fix some issues
- Display loading/missing state for list timelines
- Order lists alphabetically in overview
- Fix async list editor reset
- Redirect to /lists after deleting unpinned list
- Redirect to / after pinning a list
* Remove dead list columns when a list is deleted or fetch returns 404
* Update babel-plugin-lodash to version 3.3.2
* Update enzyme to version 3.2.0
* Update enzyme-adapter-react-16 to version 1.1.0
* Update intersection-observer to version 0.5.0
* Update intl-messageformat to version 2.2.0
* Update node-sass to version 4.7.2
* Update postcss-loader to version 2.0.9
* Update React to version 16.2.0
* Update react-textarea-autosize to version 5.2.1
* Update stringz to version 0.3.0
* Update webpack to version 3.9.1
* Update webpack-bundle-analyzer to version 2.9.1
* Update webpack-dev-server to version 2.9.5
* Update webpack-merge to version 4.1.1
* Update fsevents to version 1.1.3
* yarn upgrade
* Update active_model_serializers to version 0.10.7
* Update capistrano-rails to version 1.3.1
* Update capistrano-rbenv to version 2.1.3
* Update capybara to version 2.16.1
* Update devise-two-factor to version 3.0.2
* Update i18n-tasks to version 0.8.19
* Update ox to version 2.8.2
* Update parallel_tests to version 2.19.0
* Update puma to version 3.11.0
* Update redis-namespace to version 1.6.0
* Update rspec-rails to version 3.7.2
* Update scss_lint to version 0.56.0
* Update webmock to version 3.1.1
* Update webpush to version 0.3.3
* bundle update
* Add semi-support for Video/Image objects in ActivityPub
Video and Image objects will create corresponding status records
with manually crafted text contents (title + URL)
* Extract html-url-finding logic into JsonLdHelper
* Fallback to id when url missing, extract supported object types
* Avoid sending explicit Undo->Announce when original deleted
* Do not forward a reply back to the server that sent it
* Deduplicate inboxes of rebloggers' followers for delete forwarding
* Adjust test
* Fix wrong class, bad SQL, wrong variable, outdated comment
* Allow hiding of reblogs from followed users
This adds a new entry to the account menu to allow users to hide
future reblogs from a user (and then if they've done that, to show
future reblogs instead).
This does not remove or add historical reblogs from/to the user's
timeline; it only affects new statuses.
The API for this operates by sending a "reblogs" key to the follow
endpoint. If this is sent when starting a new follow, it will be
respected from the beginning of the follow relationship (even if
the follow request must be approved by the followee). If this is
sent when a follow relationship already exists, it will simply
update the existing follow relationship. As with the notification
muting, this will now return an object ({reblogs: [true|false]}) or
false for each follow relationship when requesting relationship
information for an account. This should cause few issues due to an
object being truthy in many languages, but some modifications may
need to be made in pickier languages.
Database changes: adds a show_reblogs column (default true,
non-nullable) to the follows and follow_requests tables. Because
these are non-nullable, we use the existing MigrationHelpers to
perform this change without locking those tables, although the
tables are likely to be small anyway.
Tests included.
See also <https://github.com/glitch-soc/mastodon/pull/212>.
* Rubocop fixes
* Code review changes
* Test fixes
This patchset closes#648 and resolves#3271.
* Rubocop fix
* Revert reblogs defaulting in argument, fix tests
It turns out we needed this for the same reason we needed it in muting:
if nil gets passed in somehow (most usually by an API client not passing
any value), we need to detect and handle it.
We could specify a default in the parameter and then also catch nil, but
there's no great reason to duplicate the default value.
* Add test for temporary account resolving failures in ProcessMentionsService
* Fix processing of mentions to already-known remote accounts on temporary failures
* Add Keyboard Shortcuts Legend
Adds a "Keyboard Shortcuts" legend (displayed in the rightmost column)
which is toggled via a new "?" hotkey. When subsequently pressed from
the Keyboard Shortcuts legend, "?" will navigate back to the previous
location.
* Add hidden table headings.
Makes the headings available for accessibility but hides them visually.
We added an index for `[account_id, reblog_of_id]`, but we already have a similar index for `reblog_of_id`. Those index will be bigger according to statuses count. For example, `reblog_of_id` index uses 800MB for 10GB statuses table.
So this patch swaps indexed columns like `[reblog_of_id, account_id]`, then it will covers both usage with single index.
Since those index creation may take a while, I've also disabled previous index creation.
* Add consumable invites
* Add UI for generating invite codes
* Add tests
* Display max uses and expiration in invites table, delete invite
* Remove unused column and redundant validator
- Default follows not used, probably bad idea
- InviteCodeValidator is redundant because RegistrationsController
checks invite code validity
* Add admin setting to disable invites
* Add admin UI for invites, configurable role for invite creation
- Admin UI that lists everyone's invites, always available
- Admin setting min_invite_role to control who can invite people
- Non-admin invite UI only visible if users are allowed to
* Do not remove invites from database, expire them instantly
Filtering the status collection wipes out even the profiles of muted and
blocked accounts. However, the behavior is inconsistent with the server-
side behavior.
* yarn manage:translations
* Add Japanese translation for #5087
* Add Japanese translation for #5616
* Add Japanese translation for #5746
* Add Japanese translation for #5750
* Serialize moved accounts into REST and ActivityPub APIs
* Parse federated moved accounts from ActivityPub
* Add note about moved accounts to public profiles
* Add moved account message to web UI
* Fix code style issues
* Add structure for lists
* Add list timeline streaming API
* Add list APIs, bind list-account relation to follow relation
* Add API for adding/removing accounts from lists
* Add pagination to lists API
* Add pagination to list accounts API
* Adjust scopes for new APIs
- Creating and modifying lists merely requires "write" scope
- Fetching information about lists merely requires "read" scope
* Add test for wrong user context on list timeline
* Clean up tests
StatusPolicy#account was renamed to StatusPolicy#current_account in
upstream. This commit renames the local-only changes to match and
augments the #show? policy spec with what we expect for local-only
toots.
* Scrub text of html before detecting language.
* Detect language on statuses coming from activitypub.
* Fix rubocop comments.
* Remove custom emoji from text before language detection
=~ made sense when we were passing it through to a regex, but we're no
longer doing that: TagMatcher looks at individual tags and returns a
value that *looks* like what you get out of #=~ but really isn't that
meaningful. Probably a good idea to not subvert convention like this
and instead use a name with guessable intent.
We already know about one regex limitation, which is that they cannot
segment words in e.g. Japanese, Chinese, or Thai. It may also end up
that regex matching is too slow compared to other methods.
However, the regex is an implementation detail. We still want the
ability to switch between "occurs anywhere" and "match whole word", and
caching the matcher result is likely to still be important (since the
matcher itself won't change nearly as often as status ingress rate).
Therefore, we ought to be able to change the cache keys to reflect a
change of data structure.
(Old cache keys expire within minutes, so they shouldn't be too big of
an issue. Old cache keys could also be explicitly removed by an
instance administrator.)
It is reasonable to expect someone to enter #foo to mute hashtag #foo.
However, tags are recorded on statuses without the preceding #.
To adjust for this, we build a separate tag matcher and use
Tag::HASHTAG_RE to extract a hashtag from the hashtag syntax.
Apparently I missed some things in earlier commits/releases that needed to be applied to the Nanobox setup. All minor things, nothing that breaks anything, but still best to get them in place.
- Move cron jobs to their own component, so the Sidekiq component can be scaled up to multiple instances without causing issues with running the same cron job multiple times at once.
- Update cron jobs to the latest requirements, removing extraneous ones
- Add new variables to `.env.nanobox`
- Update Nginx to use correct cache header directives
* Add a hide_notifications column to mutes
* Add muting_notifications? and a notifications argument to mute!
* block notifications in notify_service from hard muted accounts
* Add specs for how mute! interacts with muting_notifications?
* specs testing that hide_notifications in mutes actually hides notifications
* Add support for muting notifications in MuteService
* API support for muting notifications (and specs)
* Less gross passing of notifications flag
* Break out a separate mute modal with a hide-notifications checkbox.
* Convert profile header mute to use mute modal
* Satisfy eslint.
* specs for MuteService notifications params
* add trailing newlines to files for Pork :)
* Put the label for the hide notifications checkbox in a label element.
* Add a /api/v1/mutes/details route that just returns the array of mutes.
* Define a serializer for /api/v1/mutes/details
* Add more specs for the /api/v1/mutes/details endpoint
* Expose whether a mute hides notifications in the api/v1/relationships endpoint
* Show whether muted users' notifications are muted in account lists
* Allow modifying the hide_notifications of a mute with the /api/v1/accounts/:id/mute endpoint
* make the hide/unhide notifications buttons work
* satisfy eslint
* In probably dead code, replace a dispatch of muteAccount that was skipping the modal with launching the mute modal.
* fix a missing import
* add an explanatory comment to AccountInteractions
* Refactor handling of default params for muting to make code cleaner
* minor code style fixes oops
* Fixed a typo that was breaking the account mute API endpoint
* Apply white-space: nowrap to account relationships icons
* Fix code style issues
* Remove superfluous blank line
* Rename /api/v1/mutes/details -> /api/v2/mutes
* Don't serialize "account" in MuteSerializer
Doing so is somewhat unnecessary since it's always the current user's account.
* Fix wrong variable name in api/v2/mutes
* Use Toggle in place of checkbox in the mute modal.
* Make the Toggle in the mute modal look better
* Code style changes in specs and removed an extra space
* Code review suggestions from akihikodaki
Also fixed a syntax error in tests for AccountInteractions.
* Make AddHideNotificationsToMute Concurrent
It's not clear how much this will benefit instances in practice, as the
number of mutes tends to be pretty small, but this should prevent any
blocking migrations nonetheless.
* Fix up migration things
* Remove /api/v2/mutes
When given two regexps, Regexp.union preserves the options set (or not
set) on each regex; this meant that none of the multiline (m),
case-insensitivity (i), or extended syntax (x) options were set. Our
regexps are written expecting the m, i, and x options were set on all of
them, so we need to make sure that we preserve that behavior.
Note that this will only hide/show *future* reblogs by a user, and does
nothing to remove/add reblogs that are already in the timeline. I don't
think that's a particularly confusing behavior, and it's a lot easier
to implement (similar to mutes, I believe).
Glitch::KeywordMute's name is inferred as glitch_keyword_mutes, and in
templates this turns into e.g. settings/glitch/keyword_mutes. Going
along with this convention means a lot of file movement, though, and for
a UI that's as temporary and awkward as this one I think it's less
effort to slap a bunch of as: options everywhere.
We'll do the Right Thing when we build out the API and frontend UI.
Also make the keyword-building methods private: they always probably
should have been private, but now I have encoded enough fun and games
into them that it now seems wrong for them to *not* be private.
It is possible to cache a Regexp object, but I'm not sure what happens
if e.g. that object remains in cache across two different Ruby versions.
Caching a string seems to raise fewer questions.
Ditto for ending with \b.
Consider muting the phrase "(hot take)". I stipulate it is reasonable
to enter this with the default "match whole word" behavior. Under the
old behavior, this would be encoded as
\b\(hot\ take\)\b
However, if \b is before the first character in the string and the first
character in the string is not a word character, then the match will
fail. Ditto for after. In our example, "(" is not a word character, so
this will not match statuses containing "(hot take)", and that's a very
surprising behavior.
To address this, we only add leading and trailing \b to keywords that
start or end with word characters.
There are two motivations for this:
1. It looks like we're going to add other features that require
server-side storage (e.g. user notes).
2. Namespacing glitchsoc modifications is a good idea anyway: even if we
do not end up doing (1), if upstream introduces a keyword-mute feature
that also uses a "KeywordMute" model, we can avoid some merge
conflicts this way and work on the more interesting task of
choosing which implementation to use.
Word-boundary matching only works as intended in English and languages
that use similar word-breaking characters; it doesn't work so well in
(say) Japanese, Chinese, or Thai. It's unacceptable to have a feature
that doesn't work as intended for some languages. (Moreso especially
considering that it's likely that the largest contingent on the Mastodon
bit of the fediverse speaks Japanese.)
There are rules specified in Unicode TR29[1] for word-breaking across
all languages supported by Unicode, but the rules deliberately do not
cover all cases. In fact, TR29 states
For example, reliable detection of word boundaries in languages such
as Thai, Lao, Chinese, or Japanese requires the use of dictionary
lookup, analogous to English hyphenation.
So we aren't going to be able to make word detection work with regexes
within Mastodon (or glitchsoc). However, for a first pass (even if it's
kind of punting) we can allow the user to choose whether they want word
or substring detection and warn about the limitations of this
implementation in, say, docs.
[1]: https://unicode.org/reports/tr29/https://web.archive.org/web/20171001005125/https://unicode.org/reports/tr29/
This should eventually be accessible via the API and the web frontend,
but I find it easier to set up an editing interface using Rails
templates and the like. We can always take it out if it turns out we
don't need it.
The intent of the previous concatenation was to minimize object
allocations, which can end up being a slow killer. However, it turns
out that under MRI 2.4.x, the shove-strings-in-an-array-and-join method
is not only arguably more common but (in this particular case) actually
allocates *fewer* objects than the string concatenation.
Or, at least, that's what I gather by running this:
words = %w(palmettoes nudged hibernation bullish stockade's tightened Hades
Dixie's formalize superego's commissaries Zappa's viceroy's apothecaries
tablespoonful's barons Chennai tollgate ticked expands)
a = Account.first
KeywordMute.transaction do
words.each { |w| KeywordMute.create!(keyword: w, account: a) }
GC.start
s1 = GC.stat
re = String.new.tap do |str|
scoped = KeywordMute.where(account: a)
keywords = scoped.select(:id, :keyword)
count = scoped.count
keywords.find_each.with_index do |kw, index|
str << Regexp.escape(kw.keyword.strip)
str << '|' if index < count - 1
end
end
s2 = GC.stat
puts s1.inspect, s2.inspect
raise ActiveRecord::Rollback
end
vs this:
words = %w( palmettoes nudged hibernation bullish stockade's tightened Hades Dixie's
formalize superego's commissaries Zappa's viceroy's apothecaries tablespoonful's
barons Chennai tollgate ticked expands
)
a = Account.first
KeywordMute.transaction do
words.each { |w| KeywordMute.create!(keyword: w, account: a) }
GC.start
s1 = GC.stat
re = [].tap do |arr|
KeywordMute.where(account: a).select(:keyword, :id).find_each do |m|
arr << Regexp.escape(m.keyword.strip)
end
end.join('|')
s2 = GC.stat
puts s1.inspect, s2.inspect
raise ActiveRecord::Rollback
end
Using rails r, here is a comparison of the total_allocated_objects and
malloc_increase_bytes GC stat data:
total_allocated_objects malloc_increase_bytes
string concat 3200241 -> 3201428 (+1187) 1176 -> 45216 (44040)
array join 3200380 -> 3201299 (+919) 1176 -> 36448 (35272)
It would also have been valid to get rid of the attr_reader, but I like
being able to reach inside KeywordMute::Matcher without resorting to
instance_variable_get tomfoolery.
A matcher object that builds a match from KeywordMute data and runs it
over text is, in my view, one of the easier ways to write examples for
this sort of thing.
Gist of the proposed keyword mute implementation:
Keyword mutes are represented server-side as one keyword per record.
For each account, there exists a keyword regex that is generated as one
big alternation of all keywords. This regex is cached (in Redis, I
guess) so we can quickly get it when filtering in FeedManager.
On desktop, the compose text box grows to accommodate the content. On
mobile, the text box does not grow to accommodate text context, but does
grow to accommodate images. It is possible in both cases to overflow
the available area, which makes accessing other UI elements (e.g.
visibility setttings) difficult.
This commit makes the compose area optionally scrollable, which allows
those UI elements to remain available even if they go off-screen.
Commit 6e54719474 moved the Mastodon
variables and mixins deeper in the directory hierarchy; this commit
brings the glitch components in line with that change.
* Fix some doodle bugs and added Background color functionality
* added protections against accidental doodle erase, screen size changing
* resolve react warning about 'selected' on <option>
This fixes the StatusLengthValidator tests to use
StatusLengthValidator::MAX_CHARS to derive the length of the strings
tested, and so makes them resilient to changes in MAX_CHARS (such as the
one that made these tests fail, with it being changed from 500 to 512).
This seems a bit odd for some types of tests, but appears to make sense
here, where the testing goes beyond `status.length > MAX_CHARS`.
This will make accessibility for some things less effortful, since we won't have to define a prior event handler to do whatever should be happening by default.
* Add data- attributes to statuses for userstyle selectors
* use const and template string, replace reblog->boosted and favourite->favourited
* more template strings because sorin-sama said so
This PR adds a new notification cleaning mode, super perfectly tuned for accessibility, and removes the previous notification cleaning functionality as it's now redundant.
* w.i.p. notif clearing mode
* Better CSS for selected notification and shorter text if Stretch is off
* wip for rebase ~
* all working in notif clearing mode, except the actual removal
* bulk delete route for piggo
* cleaning + refactor. endpoint gives 422 for some reason
* formatting
* use the right route
* fix broken destroy_multiple
* load more notifs after succ cleaning
* satisfy eslint
* Removed CSS for the old notif delete button
* Tabindex=0 is mandatory
In order to make it possible to tab to this element you must have tab index = 0. Removing this violates WCAG and makes it impossible to use the interface without good eyesight and a mouse. So nobody with certain mobility impairments, vision impairments, or brain injuries would be able to use this feature if you don't have tabindex=0
* Corrected aria-label
Previous label implied a different behavior from what actually happens
* aria role localization & made the overlay behave like a checkbox
* checkboxes css and better contrast
* color tuning for the notif overlay
* fanceh checkboxes etc and nice backgrounds
* SHUT UP TRAVIS
* Locale script now accepts overrides and new keys from glitch/locales
* Revert glitchsoc changes to mastodon/locales to prevent future merge conflicts
* First lame pass at adding optional git commit hash display on /about/more page.
Currently, this is implemented by checking for the existence of a file called CURRENT_RELEASE in the home directory of the user running Mastodon. If the file exists, its contents are added.
I've modified my update process to include the following before precompiling assets:
git log -1 | head -n 1 | cut -d " " -f2 > ~/CURRENT_RELEASE
That puts the current commit hash into the file ~/CURRENT_RELEASE, but you figured that out because you're a smart cookie.
As I am quite sure this is a horrible methodology for implementing this, I look forward to any improvements you have to offer!
* Updated to handle instances that share a user - the CURRENT_RELEASE file now lives in the instance's base directory.
This also requires modifying the update hook to `git log -1 | head -n 1 | cut -d " " -f2 > CURRENT_RELEASE`
- Media toots are no longer auto-collapsed if the media is behind a CW
- Display names no longer appear clickable when a toot is collapsed
- Fixed#36 by adding reduplicating the media icon inside the SHOW
MORE/LESS
# Optional user upload path and URL (images, avatars). Default is :rails_root/public/system. If you set this variable, you are responsible for making your HTTP server (eg. nginx) serve these files.
@@ -34,7 +34,7 @@ This Code of Conduct applies both within project spaces and in public spaces whe
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at eugen@zeonfederated.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at beatrix.bitrot@gmail.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
Thank you for your interest in contributing to the `glitch-soc` project!
Here are some guidelines, and ways you can help.
> (This document is a bit of a work-in-progress, so please bear with us.
> If you don't see what you're looking for here, please don't hesitate to reach out!)
## Planning ##
Right now a lot of the planning for this project takes place in our development Discord, or through GitHub Issues and Projects.
We're working on ways to improve the planning structure and better solicit feedback, and if you feel like you can help in this respect, feel free to give us a holler.
## Documentation ##
The documentation for this repository is available at [`glitch-soc/docs`](https://github.com/glitch-soc/docs) (online at [glitch-soc.github.io/docs/](https://glitch-soc.github.io/docs/)).
Right now, we've mostly focused on the features that make this fork different from upstream in some manner.
Adding screenshots, improving descriptions, and so forth are all ways to help contribute to the project even if you don't know any code.
## Frontend Development ##
Check out [the documentation here](https://glitch-soc.github.io/docs/contributing/frontend/) for more information.
## Backend Development ##
See the guidelines below.
- - -
You should also try to follow the guidelines set out in the original `CONTRIBUTING.md` from `tootsuite/mastodon`, reproduced below.
<blockquote>
CONTRIBUTING
============
@@ -49,3 +82,5 @@ It is expected that you have a working development environment set up (see back-
* If you are introducing new strings, they must be using localization methods
If the JavaScript or CSS assets won't compile due to a syntax error, it's a good sign that the pull request isn't ready for submission yet.
Mastodon is a **free, open-source social network server** based on **open web protocols** like ActivityPub and OStatus. The social focus of the project is a viable decentralized alternative to commercial social media silos that returns the control of the content distribution channels to the people. The technical focus of the project is a good user interface, a clean REST API for 3rd party apps and robust anti-abuse tools.
So here's the deal: we all work on this code, and then it runs on dev.glitch.social and anyone who uses that does so absolutely at their own risk. can you dig it?
Click on the screenshot below to watch a demo of the UI:
**Ruby on Rails** is used for the back-end, while **React.js** and Redux are used for the dynamic front-end. A static front-end for public resources (profiles and statuses) is also provided.
If you would like, you can [support the development of this project on Patreon][patreon]. Alternatively, you can donate to this BTC address: `17j2g7vpgHhLuXhN4bueZFCvdxxieyRVWd`
- [List of Mastodon instances](https://github.com/tootsuite/documentation/blob/master/Using-Mastodon/List-of-Mastodon-instances.md)
- [List of apps](https://github.com/tootsuite/documentation/blob/master/Using-Mastodon/Apps.md)
- [List of sponsors](https://joinmastodon.org/sponsors)
## Features
**No vendor lock-in: Fully interoperable with any conforming platform**
It doesn't have to be Mastodon, whatever implements ActivityPub or OStatus is part of the social network!
**Real-time timeline updates**
See the updates of people you're following appear in real-time in the UI via WebSockets. There's a firehose view as well!
**Federated thread resolving**
If someone you follow replies to a user unknown to the server, the server fetches the full thread so you can view it without leaving the UI
**Media attachments like images and short videos**
Upload and view images and WebM/MP4 videos attached to the updates. Videos with no audio track are treated like GIFs; normal videos are looped - like vines!
**OAuth2 and a straightforward REST API**
Mastodon acts as an OAuth2 provider so 3rd party apps can use the API
**Fast response times**
Mastodon tries to be as fast and responsive as possible, so all long-running tasks are delegated to background processing
**Deployable via Docker**
You don't need to mess with dependencies and configuration if you want to try Mastodon, if you have Docker and Docker Compose the deployment is extremely easy
---
## Development
Please follow the [development guide](https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Development-guide.md) from the documentation repository.
## Deployment
There are guides in the documentation repository for [deploying on various platforms](https://github.com/tootsuite/documentation#running-mastodon).
## Contributing
You can open issues for bugs you've found or features you think are missing. You can also submit pull requests to this repository. [Here are the guidelines for code contributions](CONTRIBUTING.md)
**IRC channel**: #mastodon on irc.freenode.net
---
## Extra credits
The elephant friend illustrations are created by [Dopatwo](https://mastodon.social/@dopatwo)
- You can view documentation for this project at [glitch-soc.github.io/docs/](https://glitch-soc.github.io/docs/).
- And contributing guidelines are available [here](CONTRIBUTING.md) and [here](https://glitch-soc.github.io/docs/contributing/).
@domains=current_account.followers.reorder('MIN(follows.id) DESC').group('accounts.domain').select('accounts.domain, count(accounts.id) as accounts_from_domain').page(params[:page]).per(10)
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
