Suggestions Feed Spec, initial draft
Does the fact that this property is an object and not an array mean that each week must have its own feed? We can't have a feed for another period of time? It could be useful to have the possibility to fetch all previous activities at once when connecting a new account (but it can maybe still be done by fetching all the previous weekly feeds?).
Does the fact that this property is an object and not an array mean that each week must have its own feed?
That was the initial design, but we could also imagine nesting multiple weekly buckets in the same document, like this:
{ "suggestions": [ {"week": "2019-W24", "creators": […]}, {"week": "2019-W23", "creators": […]}, }
Another option, which I'd tend to prefer, would be to add a property linking to the previous week document, if any. This way, clients could fetch the data they need, and the format itself would remain as simple as possible:
{ "version": "0.1", "previousSuggestions": "https://alice.server.example/retribute?token=hello&week=2019-W23", … }
What do you think?
My concern was mostly about the first time you connect this platform to your client, it should be able to get all your suggestions without making hundreds of requests to the platform… so maybe there could be two different endpoints? One for the first time connection only, with all previous weeks, and then one per week?
Otherwise, I don't really like having
suggestions
as an array either, especially if it will contain only one item most of the time, butpreviousSuggestions
wouldn't really fix the issue according to me.My concern was mostly about the first time you connect this platform to your client, it should be able to get all your suggestions without making hundreds of requests to the platform… so maybe there could be two different endpoints? One for the first time connection only, with all previous weeks, and then one per week?
Is it really useful from a client/user perspective to fetch 100s of weeks of suggestions anyway? I'm genuinely asking, because my impression was that users would want suggestion based on their recent activity.
If you add a suggestion feed to your Retribute client, you probably don't want suggestions regarding your activity from 2 years ago popping up?
So, the more I think about this, and the harder it gets :D
A basic implementation to support i18n could be to provide an object instead of the string for the
name
property, with keys being locales, and values being the translation for this local:{ "id": "replies", "name": { "en_US": "Replies", "fr_FR": "Réponses" }, "suggestedWeight": 5, }
But it means that Content Platforms are ultimately responsible for something that is only displayed in Retribute clients. And as soon as we want to support more complex i18n, it breaks (because of pluralization, for instance).
Maybe we can solve this differently, and keep the Suggestion Feed format simple, as it is right now. If we defined a list of standard activities that clients should support, i18n wouldn't be a problem because clients could translate those for their target audiences.
Standardizing the list of activities (while leaving some room for extensions) would also bring other benefits, such as more consistency between content platforms, the possibility to build upon this list to improve the clients UI, etc.
What do you think @Ana?
I don't really like the idea of having a restricted set of activities, mostly because I don't really see how it could be made extensible without fragmentation (some clients may not be aware of certain activity types, because they are not standard, and thus they don't know how to translate them). So I think I18N should definitely be handled on the side of content platforms.
Maybe the
name
could look like this:{ "name": { "n < 2": "Réponse", "_": "Réponses", } }
The keys would be boolean expressions, with only one variable,
n
(the number of items), and a default case that must be called_
(or something else, I wrote it this way because that's what I usually use for default cases). Also, you can notice that I only provided translations for one language, because I thought the content platform could use theAccept-Language
header to give the correct set of translations directly.But maybe that's too much? Maybe we could do like gettext usually does, with
name
being an array, of which the first item would be the "singular" string, and the following ones the different plural forms? What do you think?I don't really like the idea of having a restricted set of activities
Me neither to be honest. But it's probably an improvement to standardize some of them (the most common), since it will reduce fragmentation? Like we have "Audio" and "Video" in ActivityPub, for instance :)
So I think I18N should definitely be handled on the side of content platforms.
I tend to disagree here. IMHO, clients should be responsible for the I18N part, because:
- It's way simpler to handle this in a handful of clients, than on literally every content platform out here (there will be way more content platforms than clients). Some content platforms may even not have any I18N mecanism in place, and be entirely monolingual.
- It means that every single suggestion feed will be bloated with I18N data, for potentially dozens of languages
- The Accept-Language header could help a bit, but it doesn't work for all the use cases (a podcast app generating a static suggestion feed file)
- The content to translate is small and displayed on client-side only.
It could also lead to some weird client behaviour, e.g If two content platforms use the same type but with different translations?