The only alternative is to store the feed for the current user in the database, rather than querying it live. That way you can exclude the posts from blocked users when you’re writing the data, rather than doing it at read-time.
This is one of the most common trade-offs you have to do when using a NoSQL database such as Firestore, where the query capabilities are often more limited than for a relational database. If you have a use-case that can’t be met with the query capabilities, you’ll have to modify your data model to allow the use-case.
Duplicating data such as I describe above (often also called fanning out data) is a common approach. While it makes the write operation more complex, the assumption when using a NoSQL database is that write operations are much less frequent than reads – so a more complicated write and storing duplicated data balances out over the multitude of reads.
If this strikes you as “unnatural” or “wrong”, consider using a relational database instead. There is nothing wrong with that – as long as you also keep in mind that most social networks use a mix of the above and relational techniques.
