Re: [Social-discuss] GNU-social features

[Joshua Judson Rosen]

On 2015-06-10 07:32, Wouter Miltenburg wrote:
> Hi all,
> 
> I am a student and currently doing research in decentralised social
> networks. For my research I've some questions about GNU social and I
> hope the mailing list is the appropriate place for these questions.
> 
> The most important question about GNU-social is its current status. On
> Wikipedia it is noted that 1.1.2 is still an Alpha release and that
> 1.1.1 is the stable release. Let's assume that 1.1.1 is the current
> stable release and 1.1.2 is the "future" of GNU social. What will be the
> aim for GNU-social and how is privacy dealt with? With other
> implementations like Friendica/RedMatrix effort was put in the privacy
> of the users. That's why I was wondering what GNU-social will provide
> for it's users. Will private/direct messages be encrypted in some form
> (or do we rely on SSL/TLS if supported by the other end)?
> 
> Will there be more advancements in federation support between different
> nodes?

The project's not dead, if that's what you're asking.

> As far as I can see you can only message someone directly, from
> another node, when he/she is added to a group.
>
> Couldn't find the option to directly post to someone's "wall" when I visited 
> his/her profile.
> More like the idea how Friendica/RedMatrix support seamless "roaming" of
> the profiles across nodes.

You can address notices to someone by @-reference using webfinger syntax,
e.g.:

        Hello, @address@hidden


Alternately: it's normal for your GNU social site to maintain local profiles
for remote users once they've been been seen or interacted with (there are
many ways that a remote profile can get into your local database--including,
I believe, if you @-reference them, if any message from them in any way
ends up on your site, if you subscribe to them or if they subscribe to you...);
and once you have a local profile for them, you can direct notices to them
via the dropdown on your site's local profile page for them.

> What kind of advancements will be made to the user's profile?

Whatever you help with :)

> How is performance and scalability be dealt with? Do we currently queue
> the messages and remove them if a node is considered "death" or when a
> user's profile is removed? Do we synchronise information every once in a
> while? How is consistency guaranteed when a node was down for
> maintenance and we want to keep information synchronised. Is there some
> kind of polling mechanism.

IIRC there's configurable `retry' mechanism that can be made to retry
sending some number of times before giving up, to guard against
`node down' or other transient errors.

There's no standard/formal definition of what constitutes a `dead node',
though--and AFAIK there's no code that attempts to automatically identify
which nodes are `dead enough' that they should be automatically 
unsubscribed-from
or that the outbound queues to them should be deleted. I haven't looked
at that code in some time, though--and I do recall overhearing something
about how more recent revisions of the PuSH protocol on which OStatus is
based actually includes some sort of automatic subscription-expiry
and periodic renewal....


-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."