ThibG [Tue, 7 Nov 2017 18:08:14 +0000 (19:08 +0100)]
Twidere mention workaround (#5552)
* Work around Twidere and Tootdon bug
Tootdon and Twidere construct @user@domain handles from mentions in toots based
solely on the mention text and account URI's domain without performing any
webfinger call or retrieving account info from the Mastodon server.
As a result, when a remote user has WEB_DOMAIN ≠ LOCAL_DOMAIN, Twidere and
Tootdon will construct the mention as @user@WEB_DOMAIN. Now, this will usually
resolve to the correct account (since the recommended configuration is to have
WEB_DOMAIN perform webfinger redirections to LOCAL_DOMAIN) when processing
mentions, but won't do so when displaying them (as it does not go through the
whole account resolution at that time).
This change rewrites mentions to the resolved account, so that displaying the
mentions will work.
* Use lookbehind instead of non-capturing group in MENTION_RE
Indeed, substitutions with the previous regexp would erroneously eat any
preceding whitespace, which would lead to concatenated mentions in the
previous commit.
Note that users will “lose” up to one character space per mention for their
toots, as that regexp is also used to remove the domain-part of mentioned
users for character counting purposes, and it also erroneously removed the
preceding character if it was a space.
ThibG [Tue, 7 Nov 2017 13:47:39 +0000 (14:47 +0100)]
Do not process undeliverable mentions (#5598)
* Resolve remote accounts when mentioned even if they are already known
This commit reduces the risk of not having up-to-date public key or protocol
information for a remote account, which is required to deliver toots
(especially direct messages).
* Do not add mentions in private messages for remote users we cannot deliver to
Mastodon does not deliver private and direct toots to OStatus users, as there
is no guarantee the remote software understands the toot's privacy. However,
users currently do not get any feedback on it (Mastodon won't attempt delivery,
but the toot will be displayed exactly the same way to the user).
This change introduces *some* feedback by not processing mentions that are
not going to be delivered. A long-term solution is still needed to have
delivery receipts or at least some better indication of what is going on, but
at least an user can see *something* is up.
ThibG [Tue, 7 Nov 2017 13:31:57 +0000 (14:31 +0100)]
Resolve remote accounts when mentioned even if they are already known (#5539)
This commit reduces the risk of not having up-to-date public key or protocol
information for a remote account, which is required to deliver toots
(especially direct messages).
Quenty31 [Fri, 3 Nov 2017 08:42:30 +0000 (09:42 +0100)]
l10n Occitan (#5586)
* Update OC: time format
Correction for time format according to: https://opinion.jornalet.com/conselh-linguistic-de-jornalet/blog/2379/la-notacion-oraria-en-occitan
Harmonisation words in menu and confirmation windows
* Update for unlisted custum emoji + #5577
* correction subjonctiu
It's either siasque or siague
* Corrections
Any : qual que, in two words, else it means "some".
And "siasque" with S even if I don't pronounce it at all.
SerCom_KC [Mon, 30 Oct 2017 03:34:58 +0000 (11:34 +0800)]
Updating Chinese (Simplified) translations (#5508)
* i18n: (zh-CN) fix punctuations and spaces
Spaces are fixed according to https://github.com/sparanoid/chinese-copywriting-guidelines
* i18n: (zh-CN) fix punctuation
* i18n: (zh-CN) Adapt official translation of Discourse Privacy Policy from GitHub, with minor fixes
https://github.com/discourse/discourse/blob/master/config/locales/server.zh_CN.yml#L2677
David Yip [Fri, 27 Oct 2017 15:05:04 +0000 (10:05 -0500)]
Add artist, title, and date metadata to boop.{mp3,ogg} (#5531)
For boop.mp3, this commit adds both ID3v1 and ID3v2 tags. For boop.ogg,
we use Vorbis metadata.
In the case of boop.mp3, this also adds a cover image. Interestingly, it
didn't seem to affect the size of boop.mp3 much, despite being ~8k.
boop.ogg seemed to be much more affected and so no cover image was added
to that version.
unarist [Fri, 27 Oct 2017 14:10:22 +0000 (23:10 +0900)]
Optimize FixReblogsInFeeds migration (#5538)
We have changed how we store reblogs in the redis for bigint IDs. This process is done by 1) scan all entries in users feed, and 2) re-store reblogs by 3 write commands.
However, this operation is really slow for large instances. e.g. 1hrs on friends.nico (w/ 50k users). So I have tried below tweaks.
* It checked non-reblogs by `entry[0] == entry[1]`, but this condition won't work because `entry[0]` is String while `entry[1]` is Float. Changing `entry[0].to_i == entry[1]` seems work.
-> about 4-20x faster (feed with less reblogs will be faster)
* Write operations can be batched by pipeline
-> about 6x faster
* Wrap operation by Lua script and execute by EVALSHA command. This really reduces packets between Ruby and Redis.
-> about 3x faster
I've taken Lua script way, though doing other optimizations may be enough.
Technowix [Wed, 18 Oct 2017 11:51:30 +0000 (13:51 +0200)]
Revert #5438 for FR (#5450)
As said here https://github.com/tootsuite/mastodon/pull/5438 the point of shortening the timestamp is legit, and after some time of adaptation no mistakes can be mades.
aschmitz [Tue, 17 Oct 2017 09:45:06 +0000 (04:45 -0500)]
Clean up reblog tracking keys, related improvements (#5428)
* Clean up reblog-tracking sets from FeedManager
Builds on #5419, with a few minor optimizations and cleanup of sets
after they are no longer needed.
* Update tests, fix multiply-reblogged case
Previously, we would have lost the fact that a given status was
reblogged if the displayed reblog of it was removed, now we don't.
Also added tests to make sure FeedManager#trim cleans up our reblog
tracking keys, fixed up FeedCleanupScheduler to use the right loop,
and fixed the test for it.
Eugen Rochko [Mon, 16 Oct 2017 18:44:31 +0000 (20:44 +0200)]
Keep references to all reblogs of a status on home feed (#5419)
* Keep references to all reblogs of a status on home feed
When inserting reblog: Add to set of reblogs of this status on
the feed, if original status was present in the feed, add it to
that set as well.
When removing a reblog: Remove it from that set. Take random
remaining item from the set. If one exists, re-insert it into feed,
otherwise do not re-insert anything.
Fix #4210
* When original is removed, toss out reblog references
Eugen Rochko [Mon, 16 Oct 2017 14:08:51 +0000 (16:08 +0200)]
Ensure that feed renegeration restores non-zero items (#5409)
Fix #5398
Ordering the home timeline query by account_id meant that the first
100 items belonged to a single account. There was also no reason to
reverse-iterate over the statuses. Assuming the user accesses the
feed halfway-through, it's better to have recent statuses already
available at the top. Therefore working from newer->older is ideal.
If the algorithm ends up filtering all items out during last-mile
filtering, repeat again a page further. The algorithm terminates
when either at least one item has been added, or if the database
query returns nothing (end of data reached)
unarist [Mon, 16 Oct 2017 13:58:23 +0000 (22:58 +0900)]
Fix un-reblogged status being at wrong position in the home timeline (#5418)
We've changed un-reblogging behavior when we implement Snowflake, to insert un-reblogged status at the position reblogging status existed.
However, our API expects home timeline is ordered by status ids, and max_id/since_id filters by zset score. Due to this, un-reblogged status appears as a last item of result set, and timeline expansion may skips many statuses.
So this reverts that change...reblogged status inserted at corresponding position to its id.
cat aescling's git repositories / mastodon.git / log