[GNU/consensus] RFC: A coder's perspective

[hellekin (GNU Consensus)]

A follow-up to "A user's perspective", originally published on
LibrePlanet[1].

Disclaimer: this article was posted in the context of the then nascent
GNU Social project. The term is kept for consistency, but it should be
understood as "any free software project that is a stakeholder in the
GNU/consensus."

= A Coder's Perspective Of GNU Social =

Following A [[User:Hellekin/A_User_Perspective_Of_GNU_Social|User's
Perspective...]], this (shorter) text explores the other side of the
application.

== I Should Be Free... ==

=== ... To Use My Favorite Language ===

I should be free to use whatever language I want.

More and more, languages are a question of preference, as a language's
specificity tends to disappear over time with new libraries, more
powerful hardware, and cross-language bindings.

Of course, Erlang and PHP are not comparable, one being conceived from
the start for maximum uptime, as well as distributed parallel computing,
while the latter started as a way to bring dynamism to static web pages.

But in general, many languages are inter-changeable according to the
coder's preference, and the target application: for speed, you'll prefer
C or C++, but for speed of development, you'll go for Python or Ruby, etc.

In any case, forcing a language on coders will close more opportunities
than not.

Update: The GNU Guile project is aiming there.

=== ... To Code For the Future ===

Although Ian Hickson announced that the HTML5 specs won't be ready
before 10 years, WebKit integrates it, and it's de facto standard on
mobile devices, making it a very good candidate for future applications.
And we all crave that WebSocket thingy.

Coding for devices supporting HTML5 offers many more possibilities that
won't be available to proprietary platforms, but it shouldn't stop me
from doing it anyway: disruptive technologies start small, don't they?
If it's good, proprietary software companies will follow, or die, or
keep their blinders on and I don't give a shit.

Update: apparently, that's what implementors do. The GNU/consensus
website itself uses HTML 5, although it doesn't use HTML5-specific tags,
for the sake of accessibility. Is there a comprehensive list of browser
support (including specialized ones to support disabilities), and a
project to "upgrade" incompatible browser?

=== ... To Ignore Market Constraints ===

When cars started to appear, the majority of people were using horses or
their feet. In our precise case, the majority of people use Facebook.
Should we follow Facebook and Microsoft, or make free software? I'm for
the latter.

That doesn't prevent the project from offering a compatibility layer,
that should actually be implemented by the different players on their
own dimes. Microsoft has long been a huge time waster for web
developers, it's time they spend a little of their own on catching up.

Not starting from market constraints imposed by alien orders provides a
lot more space for thinking out of the box and coming with real
alternatives.

It's important to realize that, if we go for a system fostering privacy,
intimacy and confidentiality, we're going for market disruption: who's
going to pay for the service, if they can't profile you?

=== ... To Use [insert project here] as a Base ===

Of course, the objective should be to make it as easy as possible for
the user to benefit from the best of both worlds: I'm not using GNU
Social for the sake of it, but for the added benefit it offers me, in
addition to being able to interact with my contacts on proprietary
social networks.

Some will prefer starting from scratch, others from an existing project.
Both solutions should be doable. Many times on the mailing-list, people
pushed their projects forward, commenting on a previous contribution on
what could be done, saying that "my project does it already" and that
kind of things. Very good, then start from your end of the line, and
come up with the missing link to the "core": what's in-between, across
and beyond Elgg, Crabgrass, PSYC, XMPP, FOAF+SSL and others, as well as
between Facebook, Wave, Twitter...

OAuth appeared as a mean for different services to provide
inter-operability, while keeping each and everyone's way running smooth.
Is GNU Social the OAuth of Social Networking?

Update: OAuth evolved in a way that is unlikely to fit our needs. Oauth
1.0a provides a better approach IMO than OAuth 2.0. We should aim for
"the simplest possible solution, but not simpler."

=== ... To Embrace the Market ===

If I prefer to cover a lot of ground and steal the user-base of
Facebook, why not? It might be the shorter path to making people switch,
to provide a Facebook-like web-based application.

But that can only work if the application is merely a GUI to the GNU
Social core engine, so that both can evolve independently. Otherwise,
duplication of effort will finally break the dream apart. On the long
term, that is useless.

== GNU Social Architecture ==

The application, or rather set of applications, come with a lot of
constraints. On the paper, it looks like the Grail. It's supposed to
embrace all visions, all devices, AND make the coffee.

The vision of "running it on any commodity server" doesn't match two of
my expectations at all:

# '''Offline mode''': how can you run GNU Social on a server, and use it
offline?
# '''Confidentiality''': how can you trust the third party server?

Update: "Offline mode" is mentioned in the GNU/consensus manifesto as
"eventually-connected-networks", a term coined by Vincenzo Tozzi, from
the Mocambos network.

=== Addressing Connectivity ===

Not all people are online all the time.  The GNU Social applications
should therefore be available for offline use.  Obviously, some cannot
be used offline (e.g. checking a friend's availability), but all the
contact management and edition should be thought of for disconnected use.

=== Addressing Confidentiality ===

In the case of third party hosting, the GNU Social applications should
make sure the server won't compromise the confidentiality of exchanges
between different parties.  That can be done by using encryption on the
client side.


[1]
http://libreplanet.org/wiki/User:Hellekin/A_Coder_Perspective_Of_GNU_Social

signature.asc
Description: OpenPGP digital signature