> could the problem of participating in the communities be solved through one app too?
My thinking is that it's a good-enough solution to leave writing comments etc. to the separate community apps. Most of the benefit the "one app" thing IMO is to provide a single feed to check--I want to have a habit of checking only one place when I have a few spare minutes to read something. While it would be kind of nice to also be able to leave comments and such without leaving that app, it's not too difficult to click on the post and leave a comment via another app. So I'd leave that kind of thing off of this list since I don't consider it to be essential. But it could still be worth experimenting with after the essentials are in place!
Another aspect to this is that protocols and interoperability have a downside since they require more coordination between different parties and can thus slow down development of new kinds of features. I think it's important to find the right amount of interop. There needs to be enough interop so that people can build new apps without having to fight against (the lack of) network effects, but not so much interop that people are unable to experiment independently with new kinds of features.
That's a long-winded way of saying I think it's actually better to not worry about making community interaction happen over a protocol, because it gives community app developers more freedom to experiment.
> How reading of different type of content should be handled,as some posts are just media, some are comments?
It may be helpful if community apps include various metadata in the feeds they provide, so reader apps can distinguish different types of posts (e.g. perhaps include a "in reply to" field for replies). When possible, reader apps can also try to infer things about the posts, similar to my suggestion of inferring if a feed is a "social feed" or a "regular feed" by looking at the frequency (and probably also the length) of posts.
> It may be helpful if community apps include various metadata in the feeds they provide, so reader apps can distinguish different types of posts (e.g. perhaps include a "in reply to" field for replies).
Fun Fact: The Activity Streams JSON-LD Vocabulary, which is used in ActivityPub, started, a long time ago, as a metadata extension for Atom (and RSS) feeds.
https://activitystrea.ms/specs/atom/1.0/
Additional Atom back in 2005 provided a minimal mechanism for copying feed items from one feed into a new feed – the "social feed" in your proposal – by specifying an element which references the original source feed.
https://www.rfc-editor.org/rfc/rfc4287#section-4.2.11
Over the years people have put a lot of time and thought into distributed social media APIs and related specs and are still doing it. Current efforts like ActivityPub and the Indiewebcamp stuff are a direct descendant of some of these specs.
(If I were you, my first thought would be to simply read, what has happened in the last 20 years. At the very least it can never hurt to know, what other people found worth doing.)
I'm interested if you have any reading recommendations? Indie Microblogging[1] is on my reading list. My impression so far of existing protocol-based social media efforts is that they're not really going in the same direction I'd like to go myself, but of course you're right that it doesn't hurt to have more background knowledge.
Both the Indiewebcamp wiki and Wikipedia often have pages on now defunct protocols and services. That is of course not a perfect approach but it gives one entry points.