[Top][All Lists]

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

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

From: Alex M (Coyo)
Subject: Re: [GMG-Devel] Plug-In Development Prerequisites
Date: Sat, 13 Apr 2013 18:23:38 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4

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!

reply via email to

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