The current mechanism to list resources in a Solid container does not support an important social media use case.

Say I'm implementing a social blog service (like LiveJournal or Facebook) that allows me to specify access control on each post: public, private (only I can see and read those posts), and friends-only.
Using the current Solid spec and implementation, I cannot simply put my Posts as resources in a /blog/ Container, and set their corresponding ACL files. This is because when an un-authenticated user (or an authenticated user who is not on my Friends list) does a List Resources request on the /blog/ container, they will see all of the posts listed on my blog, even private or friends-only ones.

In other words, as a non-friend, I do GET dmitri.databox.me/blog/, I will see that it contains:

• public post 1 (which means I have read access to it, no problem)
• private post 2 (I can see it on the list, but get a 401 / access denied when I try to request it)
• friends-only post 3 (again, I can see it on the list but get access denied)

This is completely un-usable, in terms of being able to implement private/hidden resources in the context of a social media app.

After a discussion with @deiu, @sandhawke and @nicola, the proposal is to:

• Change the Solid spec dealing with listing of containers, do not show resources a user has no access to.
• Update the relevant implementations (ldnode, etc) to match it.