Re: [Social-discuss] What I think GNU Social's structure should be

[Story Henry]

On the notion of groups. Here is how one can publish a group.
in the Turtle/N3 representation:

------- http://nongnu.org/grps/gnusocial ----
@prefix : <#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

:g a foaf:Group;
   foaf:member <http://bblfish.net/#hjs>, <https://psyced.org/~lynx/#me>, ...

----------------------------------------------

So this defined a group with URL

    <http://nongnu.org/grps/gnusocial#g>

with a number of members, all identified via their respective url. At each
of those urls the members can publish their public key (which is the 'key' 
element
inside  a PGP key, or a X509 cert)

    Now it is easy for any tool to only allow access to members of that group, 
however
they are defined, by just doing an HTTP GET on regular basis.

So go a bit further you could have another group of people on say 

<http://xwiki.org/devs/#members>

And someone could decide that we would like to have a space to work together
somewhere. IT would be easy to create a class that is the union of both these
groups, and give access to just them.

        Henry

On 29 Mar 2010, at 08:40, Carlo von Loesch wrote

> Ted Smith typeth:
> | > Not sure if you mean what I mean here, so I say what I mean. Groups
> | > of people need a managing member that generates a symmetric encryption
> | > key and sends it to each member, using each member's public keys just
> | > once. Once a secret symmetric key is established, messages can be
> | > distributed using regular multicast strategies as all members can
> | > decrypt that. Only this spells true privacy within groups of people
> | > and thus the social network. 
> | 
> | My vision is that every user will have an OpenPGP keypair tied to their
> | GNU Social identity. This could be managed by the user or totally
> | transparent to the user (managed only within the UI). A group would just
> | be a set of key IDs to encrypt to.
> 
> Yes, a group is defined by just a set of pubkeys, but by negotiating a
> shared secret you have overall less work on the sending side and you
> get the huge advantage of being able to store the message anywhere,
> distributing it more efficiently (multicast rather than round-robin
> unicast) and it is always useful to every member of the group rather
> than just one.
> 
> Also I like having some options concerning repudiability. By using
> temporary keys we can have off-the-record-like configurations, not
> always use the pgp signature which makes every little chat session
> a bit like a legally binding contract.
> 
> -- 
> ___ psyc://psyced.org/~lynX ___ irc://psyced.org/welcome ___
> ___ xmpp:address@hidden ____ https://psyced.org/PSYC/ _____
> 
>