social-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Social-discuss] On the architecture of a GNU Social node


From: Ted Smith
Subject: Re: [Social-discuss] On the architecture of a GNU Social node
Date: Sun, 25 Apr 2010 16:06:21 -0400

Did you mean to send this to the list instead of just to me? Or did
something happen with moderation/reply-all that I'm unaware of? CCing
the list just in case.

On Sat, 2010-04-24 at 00:47 -0700, elijah wrote:
> On 04/23/2010 10:41 PM, Ted Smith wrote:
> > I just posted this on libreplanet - it outlines in a more specific way
> > how I think GNU Social nodes should be built.
> > 
> > <http://groups.fsf.org/wiki/User:Teddks/Social>
> 
> Despite agnosticism in transport, I think there might have to be a
> common addressing scheme. Or perhaps addressing schemes that can be
> converted to one another.
> 
> address@hidden <=> riseup.net/elijah <=> elijah.riseup.net

This is in the realm of high-level protocol, and not really related to
the design I proposed. I do agree, however.
> 
> I also maintain that the high level protocol should be aware of three
> levels:
> 
> (1) the destination node routing information (cleartext)
> (2) the destination recipient information (enc to core)
> (3) the payload (enc to UI)
> 
> I totally agree that the payload should only be encrypted/decrypted by
> the UI layer. However, I think the destination 'core' should be
> responsible for decrypting recipient information. The destination node
> information can remain in cleartext.
> 
> Without this distinction between payload and routing encryption, the
> social graph is leaked to all the intermediaries--and if they have
> access then someone will try to make money off it in a creepy way and
> someone will give it to some government when they shouldn't.

This is (another high-level protocol thing/) something I hadn't thought
about at all, but it's totally true. The problem I see with this is that
a lot of nodes will only have one user on them. It might be worth
appropriating some onion routing/mix-type stuff to anonymize the end
recipient further, though I don't know how that would work for having a
relationship, though.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]