Current Container Listing mechanism does not support hidden resource use case

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.

Start by reviewing the Solid specification's container-listing section and the discussion referenced in the issue. Then inspect ldnode and the other relevant implementations mentioned. Done means the specification and implementations consistently omit resources the requester cannot access.