Re: [GMG-Devel] Plug-In Development Prerequisites

[Alex M (Coyo)]

On 04/10/2013 09:49 PM, Alex M (Coyo) wrote:
> There are a few specific plug-ins I am very interested in developing.
>
> 1) Active Directory Authentication
>
> (LDAP + Kerberos + DNS, by way of SAMBA) Active Directiory plugin for 
> unified user authentication among multiple mediagoblin instances 
> within a site domain. Useful for use cases involving multiple 
> mediagoblin instances that are not synched with a single database.

I suppose I could use plain LDAP or a personal form of LDAP + Kerberos 
and/or Radius, but I need the samba active directory experience anyway.

> 2) Social Network Federation
>
> StatusNet/OStatus/PumpIO social network federation, possibly with 
> Diaspora/TentIO and Friendica/Zot/Red protocols on the distant roadmap 
> with the same python federation library.

I suppose we could start with PumpIO implementation.

I'm not a fan of javascript, though I AM a fan of the asynchronous 
event-driven actor model.

It makes it really really easy to quickly code P2P network applications, 
scale up virtually as large as you could want, and since actors all act 
independantly, it's fairly straightforward to add 0MQ+MsgPack RPC to 
permit interprocess communications between machines.

I wish an equivalent framework existed for python. Before you say it, 
Twisted is ***NOT*** an equivalent framework, it's not even a framework, 
and it's not asynchronous, must less actor-oriented.

The only real similarity is the existence of a Reactor object. That's 
about it.

> 3) Extended Social Functions
>
> Specifically: journals, submission feeds and pub/sub, distinct 
> submission channels (sub-contexts), threaded comments on submissions, 
> submission replies (reply to a submission with a submission), interest 
> groups and sub-communities (user groups you can submit media and 
> journals to, in addition to microblogs and commentary)

These features are 100% mandatory if the mediagoblin project wishes to 
be a serious influence on the Internet's openness and liberty.

> 4) Integrated Chat
>
> (via libpurple) Extensive chat, including groupchat. Would preferably 
> be tied to a chat server hosted by the same domain (or a sub-domain). 
> Preferably would include voice and video chat, but obviously that 
> comes after textual group chat. May automatically manage and 
> instantiate skype group chats with skypekit running over wine.

We can argue all month about Skype's proprietary nature, but until I see 
a real alternative, in other words, trivial (and free) group video over 
IP, no FOSS project is really an alternative. Asterisk is awesome, but 
the conferencing features are extremely limited, group voice tends to be 
extremely taxing on the server, SIP in general takes a very naive and 
crude approach to NAT hole punching and stateful firewall circumvention.

SIP just sucks in general.

Jingle will never be a serious alternative, I think. MuJi (Multiparty 
Jingle) is at the absolute bottom of the priority pile, and XMPP/Jabber 
developers are lazy bums.

They have irritated me to the point where I am tempted to develop a 
0MQ+MsgPack RPC version of the XMPP protocol and add a ton of 
proprietary extensions for the sole purpose of annoying and excluding them.

How this would work is re-implementing the core jabber/xmpp 
specifications in the relevant RFCs and core XEPs, but throwing out XML 
wholesale, giving the existing xmpp federation the finger, and pointedly 
discarding the concepts of "standing on the shoulders of giants," 
"maintaining compatibility with older clients," "maintaining 
compatibility with the xmpp federation," "enforcing human-readability," 
and "enforcing strict exclusive text-only protocol openness."

Instead, we'd take a very aggressive and deliberate 
compatibility-breaking attitude and approach, making the protocol pure 
binary-only, deliberately and pointedly relying on specialized libraries 
for protocol implementation, deliberate and pointedly overt avoidance of 
using XML, JSON, BSON, Bencoding or any other high-level abstracted 
serialization format for anything.

We'd give users, admins, and plugin developers the freedom of tunneling 
JSON or whatever within message buffer objects passed as a parameter 
within the binary RPC protocol if they are that much a bunch of 
masochists, but that doesn't mean we won't laugh at you for doing so.

Though, considering how lazy the XMPP developers are, I could release 
the nonstandard extensions as AGPLv3 and simply not fully document it or 
fully comment the source code, and chances are they won't bother to 
reverse engineer the protocols. They can't be assed to work for a living.

It also doesn't help that XML streams, end-to-end stream encryption, 
encryption in general, absolutely anything P2P or security-related, 
anything related to social networking (BuddyCloud is being developed so 
excruciatingly slow as to be barely worth mentioning), and the 
dependance on TLS PKI is beyond naive, recklessly endangering every 
jabber user in existence.

DNSSEC, DANE, DNSCurve and DNSCrypt would make certificate authorities 
(who have a long and disgusting history of betraying their clients and 
their clients' users by traitorously submitting like little sheepish 
cowards to demands by the State to collaborate in warrant-less domain 
seizure, wiretapping,  traffic interception and outright blatant 
certificate forgery, unashamedly and unapologetically abusing their 
position of trust. Cowards and traitors, all of them. Bunch of 
traitorous cowardly bums, every last one.

With DNS extensions such as those previously mentioned, it would be a 
lot more difficult to forge certificates, interfere with zone answers, 
deceive or subvert naive users or server admins, or otherwise abuse 
their power, trust, responsibilities and authority.

At least with DNS, it's a lot easier to simply deploy your own 
alternative root, mirror ICANN TLDs and their authoritative nameservers, 
deploy your own tier 2 caching resolvers, and use nonstandard extensions 
and protocol obfuscation to resist subversion, coordinated state-level 
attacks and various attempts at denial-of-service, man-in-the-middle, 
sybil or infrastructural attacks and subversions.

So, bottom line, the TL;DR version of my argument regarding skype and 
the FSF's naive attitude toward dynamically linking to non-free 
libraries, shared objects or frameworks is basically,

"You have something better? No? Then STFU and GTFO."

"Give me an alternative, or get out of the way."

The only real alternative to skype is an equivalent decentralized and 
P2P attack-resistant, censorship-resistant and privacy-protecting 
overlay network that is low-latency enough, secure enough, resilient 
enough to NATs, stateful firewalls and IDSs, and efficient enough to 
support:

* Distributed P2P group voice and video chats

* Teamspeak/Mumble-like serverless decentralized P2P game-oriented voice 
telephony

* Distributed P2P SocNet (FOSS alternative to Facebook, DeviantArt or 
YouTube, basically a scalable P2P version of MediaGoblin)

* Distributed object storage, P2P filesharing, virtual distributed 
versioning filesystems, and scalable low-latency data stores

* Trivial decentralized VPN tunneling (P2P FOSS alternative to hamachi 
or remobo)

* Screen-sharing, remote access and control, remote administration and 
management

* Resilient and secure SSH authentication

* Fully-feature-packed instant messaging with extremely scalable 
distributed chat rooms (infinitely superior P2P alternative to IRC, 
Jabber, Zephyr, Bonjour and PSYC, as well as any conceivable non-free 
protocol or network)

* Distributed forum-like threaded discussions (superior P2P alternative 
to mailing lists or web forums)

* Distributed P2P MUD/MUCK-like massively-multiplayer serverless online 
roleplaying games and/or virtual worlds with more features and 
scalability than either secondlife or over-provisioned opensim grids

* Extremely efficient layer-2 switched hardware-accelerated overlay for 
the wholesale disposal and replacement of DNS, Ethernet, TDM Optical 
Carrier, SONET, IP, BGP and any need for centralized address space or 
ASN authoritative allocation

* Extremely efficient ECC public key based layer 2 switching fabric with 
IS-IS-like and TRILL-like behavior with no distinction between layer 2 
and layer 3 addressing. ARP does not exist, broadcasts do not exist, any 
distinction between residential, business, enterprise, service provider, 
carrier and content provider networks or protocols do not exist

* Absolute and explicit eradication of HTTP, SOAP, XML, JSON, the Web in 
general, port numbers, centralization of any kind, hierarchical network 
structure, authoritative named entities, any possibility for state 
privacy breaches or abuses and any distinction between client and server 
roles.


With these features, you would not need skype, or any of the crap that 
holds the Internet back (and yes, the Internet Protocol itself is to 
blame, along with HTTP, TCP, BGP, and Ethernet)

If you created a layer 2 overlay-style switching protocol, and 
eliminated the distinction between framing and packet forwarding, 
combining layer 2 and layer 3, pointedly and disgustedly throwing out 
the OSI model in the process, and instead used a more MPLS + TRILL + 
IS-IS style switching protocol, replacing all MAC or IP addresses with 
ECC public keys and integrating a P2P WOT-style certificate verification 
and revocation as an integral and mandatory protocol in the core 
protocol stack, while integrating heavily modified MPLS/CJDNS, 
TRILL/LISP, IP Multicast, and integral IS-IS-style routing into a single 
unified and cohesive protocol as part of a larger cohesive core protocol 
stack.

End-to-End tunneled ECC is a mandatory core feature, and switched 
MPLS-style over a TRILL-like minimal point-to-point line protocol. 
Mandatory and universal use of ROADM DWDM with advanced compression and 
optical channel multiplexing (such as using really advanced bit-coding, 
polarization multiplexing means that bandwidth is rarely a concern.

Anyway, if you are interested in my ideas for a wholesale replacement 
for the Internet's core protocols and flaws, poke me at my email 
address. I'm going to visit a CCIE-certified  senior network engineer 
friend of mine at his townhouse. See ya!