Spaces Are not truly nested

We are testing Spaces, which are essentially Groups except that you can nest them.  In the simplest form let's say you had a neighborhood, Town, and State. 

The Neighborhood is the child of the Town and the State is the Parent of the Town.  So in our test by joining the neighborhood, you are not automatically a member of the Town and State.   Are there settings that need to be turned on?  We have hierarchy turned on.  

If by joining the child group you are not automatically put in the parent Group, what exactly is the point of Spaces?   And if we have it set up wrong, please enlighten me. 

Thank you.  

  • 1003
  • More
Replies (7)
    • Yes, correct, they're not nested in a sense that following a child auto-follows parent spaces. First, it may not be an expected behaviour (say, I want to follow my town Space, but not my Country space - that would be too much noise). Similar to how when you put a file into a subfolder it can only be found in that subfolder, not in the parent folder. 

      You are, however, touching on a very important issue of systems architecture in general - why not attribute associations with a child to parent context? In some cases, it may be useful but rarely happens because it requires recursive queries that can be very resource-intensive and can be exploited in DDOS attacks or may lead to looping problems in incorrect configurations.

      It is possible to configure Spaces to have unlimited nesting, auto-following of parents and upstream publishing of content, but it must be done carefully in every configuration case.

      • Ok but what is the point?  What is the value of having a Group inside the other Group it is purely for show; if there is no accompanying functionality with having something nested?  

        • Sorry, I can see how I sounded confusing in my reply. 

          You can, and perhaps should have some kind relationship between Parent and Child spaces besides simple reference. The thing is that can't see one commonly acceptable approach that would make sense in every scenario. So, the Spaces module is much like a prototype module, which we use to create a modified version for each specific idea. 

          Here's a hypothetical scenario: 

          - A site for US universities students. Each member must have an email in their uni domain. Spaces for each uni are pre-created. Members are auto-assigned to their university space according to their email domain. 

          - Parent spaces for each State in US are created and universities are assigned as child-spaces into their respective states.

          - The second level of children spaces are created for, say, faculties in each uni.

          - The task is to make sure that students socialise, collaborate and share with a good level of relevance, without too much noise.  

          ....

          We would have to configure spaces somewhat like this:

          - Auto-assign profiles as members of specific university spaces according to their email domain.

          - Make faculty-level spaces invitation-only or "approval required", so that admins of the spaces approve members (because we can't programmatically know to which faculty a student belongs). 

          - Allow Students (membership level) to post to Faculties only - the most ambient level of spaces.

          - Allow Staff (membership level) to post to Faculties and University spaces. This will ensure that only high-level announcements go into those spaces and the potential for spam or rogue/unsafe content exposure is contained.

          - Push "popular" posts upstream with a certain daily limit (say, 3 most liked posts from each faculty go into University and 3 most liked posts from University goes into State) - this will control noise and curate the best content for more exposed spaces.

          - Set students to auto-follow their University and Faculty spaces, and recommend to follow State. Perhaps, allow them to follow other spaces if they want to.

          - All of the above will populate their feeds. Naturally, they may be choosing to also follow specific students or teachers or groups if they want to. 

          __________

          See, this is just one potential application scenario. Your idea may be completely different, but you always need to look for ways to make feeds populate with the most relevant content with digestible pace. Say, if you auto-assign a Student to a State and push all posts from all State subspaces upstream, then the feed of the Student will be full of content from various universities, different faculties, etc, which may quickly become unusable and Facebook-like. 

          And when I say Facebook-like I do mean it in a bad way. See, Facebook curates content in their so-called "smart feeds"  based on two main factors - what makes more money and what makes you use Facebook more. In most cases, it boils down to observing your tendencies and rehashing them - if you like a "right-wing" posts, your feed will be predominantly populated with "right-wing" content, and vice versa. As a result, everyone is living in their own version of a virtual comfort zone - an information bubble that we first trigger by our choices and then Facebook algorithms reinforce manyfold. This is a horrible, disgusting, appalling effect, which should be disrupted - it inevitably feeds division between people. (sorry for digressing - it's a topic that's close to my heart, so to speak). 

          • i agree with you Andrew Boon with code you cant be too careful exploits will be found if the hacker or attacker is persistent on there en-devour man in the middle attacks ddos phishing attacks kernel exploits queries leaks from a bad set up of search functions there all that has to be thanked about when coding software or a feature.

            • Something like categories with subcategories?

              • Or breadcrumbs... This will be very helpful! image_transcoder.php?o=bx_froala_image&h=4913&dpx=1&t=1615773489

                • Think of spaces as a hierarchical framework.  The people in the Neighborhood know which town they're in, and which state they're in.  Maybe they want to participate in the Town's affairs, maybe they don't. If they do, they can click that join button on their town or State... but it's not something they should be forced to do.  Then there's the case of being a member of a neighborhood in Town #1, but your home town is 1000 miles away, so you join that town as well.  Oops.... there goes your idea of what a hierarchy should be.  

                  Spaces just provide that hierarchical structure that glues all the different spaces together.  Consider this example for just one branch of a hierarchy : Space #1 is "Director of engineering".  The Director's space is parent to 5 child spaces belonging to managers.  Each manager has an average of 20 child spaces for employees that they manage.  In this case, should all those employee child spaces be added to the Director's space?  The short answer is no, because it diminishes the hierarchal structure.  Look at any org chart for any company on earth, and it will have the same structure as Spaces.  In fact, you could use Spaces to build a unique social media representation of the traditional organization chart, but instead of blocks on a chart, you have Spaces,   In this case, the entire structure would have to be managed so that its structure remain true to the actual hierarchy.  It would make an interesting network

                  In your case, members of neighborhoods are indeed members of towns as well as States, but they are bound by hierarchy, not just dumped on one big pile.

                  Login or Join to comment.