Facilities I'd like to offer in a later version

From Alistair Mann / csi18n
Revision as of 18:31, 17 December 2014 by Alistair Mann (Talk | contribs) (Fixed IP)

Jump to: navigation, search

A wish list of facilities I'd like to add.


csi18n currently supports resources with a limited set of text-based mime types, such as text/plain; text/html etc.

It would be useful to store binary types too. Examples:

  • image/png. A specifically created overlay on top of a cartoon could render alternative language text 'as if' it was part of the original.
  • audio/webm. Hear/record/distribute a translation of that TED lecture dialog in your language - no reading skills required of your audience.
  • video/mp4. I could imagine intertitles making use of this, I could imagine public service announcements using it too.
  • application/vnd.ms-powerpoint. Do you use these presentations as a teaching aid? How useful would it be that alternate language versions were available?

With binaries, people would also be able to upload suggested translations of (say) Glaswegian English from video into a voiceover ... which would see the translation with broader acceptance bubble to the top.

Docker access

Not strictly speaking part of this project, but it would be very interesting to hide servers behind docker-based caching servers.

Fixed IP

Who knows what the current IP is, or how long it will last? Not me, for sure. DDNS can only take things so far.

At the moment, the server can be down for upto half an hour after an IP address change: icmp is used to check every 15 secs, the demopage server will check if it needs to adapt it's firewall to that change every 15 seconds, but ddns itself may not complete the changes for some time. Even if fixed, it would take 15 minutes for other DNS servers to pick up my 900s TTL, so improving DDNS < getting Fixed IP.


It's astonishing that IPv6 is still not supported at the consumer level. It is available from datacentres, so I'd expect to offer IPv6 access as and when service can be provided from such a place.

Local caching

All requests received are routed directly to the origin server. For testing purposes as well as performance reasons, I'd prefer to route traffic first to a local cache, even a load balancer if warrantied.

Local servers

There is just the one server right now. It would be useful to have several around the world, with replication between them, leaving software clients to work out which gives best service.

RFC7230-7 Compliance

HTTP/1.1, as used by this service, was defined by RFC2616. Since June 2014 it is now defined by RFCs7230 thru 7237. I would like to revisit the service to make it comply with those new RFCs.


It would be of use to form some kind of a ranking system such that interested parties can discover higher-quality uploaders. Or perhaps discover lower-quality uploaders, or both. Similarly, it would be useful for uploaders to see subscribers who best treat them.


Security cannot be taken too seriously. I would commit to:

Inside-Out escalator

Were there funds to do so, I'd contract someone to Blue Team the existing security. I've done the best I can, but I doubt that's enough. Blue Teaming would happen regularly, with successive reviews getting more and more demanding.

Outside-In attack platform

It'd be interesting to offer up a server 'A' to be attacked and a Internet-accessible server 'B' from which Red team attacks could be launched against 'A', over a private network between the two. A DoS against the server 'A' or an attack against server 'B' would not count as a succesful attack.

User to user contact

If one user wants to contact another user, it would be useful to facilitate that. For instance, suppose user X provides consistently good translations into Arabic, and so user Y wants to invites user X to a further project.

Such a service could be a cross between fingering and pseudonymous remailing: user X can elect to expose data or not, and take advantage of the service forwarding a message without revealing Xs contact details; user Y can send a message but does not know more about X than X has chosen to reveal. X can at that point take the approach to some other medium like email, or block Y altogether.


The existing implementation requires client software to specifically poll for updates. An advantage of WebSockets is that change-polling can be shifted to the server, thus saving bandwidth and improving responsiveness.

With WebSocket support, csi18n would provide a more seamless background for realt-time collaborative endeavours.