As of the `v2.0.0` release of this project, only users who are authenticated with a particular OAuth server can _create_ feeds. Any federated user can still read the feeds. I implemented this because running this service in the open invited thousands of spammers to create feeds and overwhelm the service. With this new model, you can run this as an added bonus for people in a community like a Mastodon server, and as the person running it you are taking on only the moderation burden of the users you are already responsible for on your federated server.
Mastodon 2.9.2 now supports native audio attachments, so
any mp3 enclosures detected from a podcast-style feed
are converted to an audio attachment of the form
"attachment": {
"type": "Document",
"mediaType": "audio/mpeg",
"url": "[URL of the mp3]",
"name": null
}
Since we're not checking mime types anyway, and most browser
supported image formats should probably render as attachments
on Mastodon and Pleroma, I'm removing this. There are often
normal JPEG and PNG images that get linked as an img src but
lack the standard file extensions, especially if it comes from
an API that returns the file binary.
Closes#36.
This commit mostly fixes the duplicate messages issue. What was happening was I was creating multiple Note objects if I was sending a Note to multiple people. Instead I create one Note object and reference that in multiple Create events.
* change the way updateFeeds works so that it loops correctly through all feeds and doesn't hang
* make posts unlisted by default in Mastodon ('cc' the public collection rather than 'to')