#Retroshare 0.6.1 full#

In v0.6.1, they can also be used to limit the distribution of forums/channels/posted as well. They have been used already for limiting the access of shared file lists. Groups of neighbor nodes are what we call “Local groups”.

Not all of them are made accessible by the GUI, but can be used right away by plugins to implement a new types of media. Many (Probably non all tested) options potentially exist in this system, including pairs of circles restricted to each other, the possibility to limit the distribution of pseudo anonymous identities to a particular circle, the possibility to limit circle distribution to a local group of nodes, etc.

#Retroshare 0.6.1 full#

For obvious reasons self-restricted circles are propagated encrypted to the “invitee” list, instead of the list of full members. As such, the administrator of the circle not only limits the membership of people but also who can be aware that this circle even exists. With this, we can create “self-restricted” circles, which will only be visible to people in the “invitee” list. Now, let’s complicate this thing a bit further: since circles are also “GXS groups”, they can be themselves restricted to other circles, including themselves. With this system, circles can contain anonymous IDs as well as signed IDs. Doing so, only people which are true members of the circle are able to see and handle that data, and to request and send message content. forum IDs, etc) for the set of members, using envelop encryption. Security of circle-restricted forums/channels/… is ensured by encrypting the data for the message IDs, and group Meta Data (e.g. Status: states whether you are a member or not. Unless restricted to another circle, they are made visible to your neighbour nodes, so that people in this node can e.g. The later means you created the circle, which allows you to grant membership, and invite people to be a member. Your role: you are either a “user”, or an “admin”. A circle can indeed be restricted to another circle (see “self-restricted circles” below). Circle ID: This allows you to disambiguate which circle you’re dealing with. Tooltips on each circle tree entry give information about: request membership for one of your identities, or grant membership if you’re the administrator of a circle A contextual menu in each circle and each invitee/member of a circle allows you to act appropriately. Yellow means that you’re either applied and are waiting to be accepted, or invited and have the possibility to accept to be a member The bullet displays information about your status. “Circles I belong to”) and other circles. The GUI displays circles for which you are a member (a.k.a. This two-way membership not only allows people to request membership, but also prevents arbitrary circles to be created in order to spam unwanted information/data through neighbour nodes Only the administrator of a circle can grant you, by adding you in the “invitee” list. People need to meet two conditions in order to be a member of a circle: they need to “apply for membership” and they need to be “granted as member”. The downside is that the whole thing can be a bit scary A lot of options and handles are available there, for maximum flexibility. A new tab in “People” allows you to create/modify them. External circles represent sets of pseudo-anonymous identities. They stand for the base architecture element of a future social network layer. Both features considerably enhance the privacy of media that uses them. The choice is available when creating, or when editing the properties of a forum. This happens in two different ways: limitation to a group of pseudo-anonymous identities (the ones in People), or limitation of a group of friend nodes (the ones in Network). Forums, channels and posted threads (and any entity represented by a a “GXS group”) can now be limited in their distribution.

iphone-sms-backup-and-restore (2.14.- Group-based privacy for channels/forums/posted:.

apache-tinkerpop-gremlin-server (3.3.10).

apache-tinkerpop-gremlin-console (3.3.10).

I will avoid unsupported or EOL releases. This is primarily a tracking issue for myself with the intent to add packages not yet included from Scoop, make sure they use static installer links, ensure the right installer types are being used, and include as much information possible in the manifests (such as descriptions, tags, cli names ,etc.).