This fork of TootSDK is geared toward supporting Fedicat and changes daily with a lot of messy reorgs - in theory it's generally usable but in practice very unstable. If you're interested in this code, I recommend first trying the official branch (TootyGraph is a fully open source app using TootSDK), and then you're welcome to try or borrow these added features (and feel free to patch back to the original repo).

A lot has been removed (or not updated from the official branch) to simplify maintenance, including the demo, vapor, and admin packages, and any features I'm not using. Only iOS compatibility is targeted, and pretty much just the latest.

The major functional difference is the removal of TootFlavour/TootFeature checks performed by TootClient and instead a Platform hierarchy of classes that mirrors fork relationships (making it simple to add new platforms) and allows checking API and build versions for feature detection. Platform is optional (was originally a separate package, there is no dependency except that nodeinfo and instance can derive a platform) and used by the higher application layer (rationale that feature checking is required for appropriate UI). Fedicat references Platform and TootClient mostly through a session layer. Since there is no platform detection within TootClient it's more a union of platform APIs rather than a unified API.

You may also be interested in the endpoint-mapped flavour/feature enumeration in Feditext (they also have a complete nodeinfo reader) and a proposed extension.

Other additions include an object-oriented layer in TootClient so for example boost(post) instead of boostPost(id: post.id), and protocols that define common interfaces, e.g. Post and PostEdit implement a Published protocol.

Organization of the day:

• Request params are Encodable while models returned are Decodable. Data that can be either are Codable (mostly enums).
• Models mostly are defined corresponding to the API doc, (primarily Mastodon, but a little bit of others), or by looking at their code.
• The decoder is relied upon to clean up data (trimming whitespace, reading ints as strings and vice versa, removing empty lists amd strings, removing duplicates in lists) and construct appropriate representations such as URLs, e.g. ISOCode enumerates supported language codes, MIME for MIME types (see SwiftUIKit for a more elaborate set), OAuthType for scopes. This makes things easier for the higher level code at the risk of decoder failures, but for now I want to identify the breaking cases.
• The low-level TootClient params are internal (mostly), so where they are used there is a wrapping public interface with separated (and often converted) parameters.
• Formatted and linted with swift-format (default rules).

Source code is under the BSD-3 license but doesn't cover the test data not authored by contributors (e.g. instance privacy policy text)