In 2009 we had a major discussion about Strategy: Where does PSYC go from where it was.


Update May 2011: So far the PSYC vision has been a bunch of cool ideas without an obvious target application that makes it palpable to everyone. Recently I came up with crypto sharing which is just one out of many possible PSYC applications, but trying to get there is easier to focus on than just wishing for the abstract 'PSYC vision'. Also having discussions with the folks on GNU Social and looking at darknet technologies have reshaped our view on things, especially concerning our privacy expectations, so what we effectively chose to do of the following options is: We did indeed implement libpsyc and are plugging it into existing PSYC software. Additionally we see a need for a very lean and fast PSYC routing daemon to be run on each and everybody's computer, that's why we are ruling out psyced for this. In fact we are ruling out any bytecode or interpreted language, thus the best candidate for this currently goes by the name of Saikound.


November 2011: Crypto sharing has turned into secure share and is gaining interest from the outside world, as it has a much clearer vision than just a bunch of technologies coming from the history of chat. With libpsyc, Saikound and psycd we are moving forward quickly to a new dimension of PSYC where the focus is on privacy, portability, scalability and social features on a whole new scale. Twenty years of research are finally coming to fruition.

Here are the choices we actually made since the 2009 Strategy discussion:

  • Since there is never a way to agree on everybody's favorite pet programming language, we chose the one most likely to operate efficiently even under embedded or smartphone conditions, C. We lost 70% of our volunteers because we didn't chose their favourite language..  ;-P ... but I'm very glad we didn't embark on interpreted/bytecode languages any further.
  • We actually chose C because we needed libpsyc to be integrated in any language in order to make development of PSYC apps easier.
  • Once we had libpsyc doing its job, tg preferred to go further in C rather than to enjoy the pleasures of D, but not being sure if we can actually deploy that everywhere. That's why we now have both psycd and Saikound. psycd being more focused on doing minimal networking for secure share while Saikound is more like a traditional chat server.
  • An independent test suite never materialized, but the one in libpsyc will do.
  • Doing a benchmark for libpsyc cost us some extra time, but it gave us solid data for argumentation. Knowing that our ideas aren't all stupid, in fact, that they are a lot better than we expected, has solidified our motivation.
  • Meta-programming is currently not of interest. Binding a C implementation is a more powerful plan in most cases. Since we can't invent a meta language that will produce both efficient C and Javascript at the same time, JS being the most important language next to C, we might as well just implement these two whenever the need arises.
  • The specs didn't need all that much work after all, elmex and others did a good job putting the specs on their feet in 2008. We have been fixing and adapting details as we progress with implementation.


February 2014:

  • In 2012 we had a secushare prototype based on psycd and GNUnet. It provided for distributed encrypted chatrooms, but it would require a bootstrap of all participants at each run - reconnecting to previously met people didn't work.
  • tg chose to focus on the GNUnet integration, pubsub and multicast API. All the relevant code is now directly in the GNUnet repository.
  • Both Saikound and psycd are discontinued. libpsyc seems stable. psyced is in maintenance mode.
  • We spent some time trying to get funding, but it took last summer's events to actually bring that funding our way.
  • Last summer also spawned #youbroketheinternet
  • There is again discussion that we should have a higher level language to implement upper layer things in, rather than C, as long as it doesn't explode code sizes or otherwise exceed the limits of typical free hardware installations. A comparison of candidates is in the making.
  • The spec is planned to consolidate on a lot of actual details in order to implement the majority of functions. It may happen in a new tool outside this wiki.