mastodon - Plural Café fork of Mastodon/Glitch Social

Age	Commit message (Collapse)	Author
2017-08-14	Hook up URL-based resource look-up to ActivityPub (#4589)	Eugen Rochko

2017-05-31	Clean up api/subscriptions controller (#3448)	Matt Jankowski

2017-05-03	Fix #2706 - Always respond with 200 to PuSH payloads (#2733)	Eugen Rochko
	Fix #2196 - Respond with 201 when Salmon accepted, 400 when unverified Fix #2629 - Correctly handle confirm_domain? for local accounts Unify rules for extracting author acct from XML, prefer <email>, fall back to <name> + <uri> (see also #2017, #2172)
2016-11-26	Update hub URL and re-subscribe if hub URL changes	Eugen Rochko

2016-09-26	Fix #54 - Fetch remote accounts by URL from mentions	Eugen Rochko
	Fetching atom extracted from FetchRemoteAccountService and FetchRemoteStatusService into FetchAtomService. Mentions of the constant "http://activityschema.org/collection/public" skipped as it's not a real URL/user.
2016-09-21	Fix #24 - Thread resolving for remote statuses	Eugen Rochko
	This is a big one, so let me enumerate: Accounts as well as stream entry pages now contain Link headers that reference the Atom feed and Webfinger URL for the former and Atom entry for the latter. So you only need to HEAD those resources to get that information, no need to download and parse HTML <link>s. ProcessFeedService will now queue ThreadResolveWorker for each remote status that it cannot find otherwise. Furthermore, entries are now processed in reverse order (from bottom to top) in case a newer entry references a chronologically previous one. ThreadResolveWorker uses FetchRemoteStatusService to obtain a status and attach the child status it was queued for to it. FetchRemoteStatusService looks up the URL, first with a HEAD, tests if it's an Atom feed, in which case it processes it directly. Next for Link headers to the Atom feed, in which case that is fetched and processed. Lastly if it's HTML, it is checked for <link>s to the Atom feed, and if such is found, that is fetched and processed. The account for the status is derived from author/name attribute in the XML and the hostname in the URL (domain). FollowRemoteAccountService and ProcessFeedService are used. This means that potentially threads are resolved recursively until a dead-end is encountered, however it is performed asynchronously over background jobs, so it should be ok.
2016-09-20	Upgrade to PubSubHubbub 0.4 (removing verify_token)	Eugen Rochko

2016-09-08	Fixing atom feeds for accounts, adding tests that would catch such bugs in ↵	Eugen Rochko
	future
2016-08-17	Upgrade to Rails 5.0.0.1	Eugen Rochko

2016-03-21	Ancestors and descendants of statuses	Eugen Rochko

2016-03-20	Writing out more tests, fixed some bugs	Eugen Rochko

2016-02-29	Refactoring Grape API methods into normal controllers & other things	Eugen Rochko