Current and future development

From diaspora* project wiki
SpeculativeSpeculative:This article is a work-in-progress. This article is currently a speculative draft based on user feedback and developer needs. As such, it should not be interpreted as a canonical source of future information until the details are more further refined. improve the article by updating it. There may be additional information on the talk page.

We thought it would be useful write a bit about what's going on with Diaspora development, as a major update, version 0.1.0.0, has recently been released and warmly welcomed. This release included a couple of features, such as post previews, that people have been asking about for ages. It's easy to feel that nothing is happening even when there's a lot going on in the background, as development in a large project such as this can take a long time. However, we're trying to improve communication within the community, so that everyone is better informed about what's going on and what progress there is on certain elements of the development.

Needless to say, if you think you can help in any way with the development of Diaspora, please make yourself known on Github. There is a specific 'newcomer' tag which marks projects suitable for someone who's new to Diaspora's code; these can be found here.

Sean Tilley (deadsuperhero@joindiaspora.com) started this thread recently asking people what they would like to see Diaspora be like in a year's time. There were many suggestions, and this post is an attempt to address as many of them as possible.

First there are the fundamental parts of the software that make the Diaspora network operate.

Fundamental code

Sort out federation

If you don't yet know what 'federation' refers to, it's the sharing of data between pods in a decentralised network. It worked pretty well when Diaspora launched, but as the network grew in size (both the number of pods, and also large numbers of users on certain pods) flaws in the design became apparent and more problematic. Since then a lot of work has gone into trying to solve these problems so that data stored on one pod are successfully and instantly shared with all other pods which need to receive them, but this has been without doubt the most complex problem facing Diaspora's developers, and as yet the issues have not been fully solved. Even though it may seem that very little has happened, an awful lot of work has been going on behind the scenes to improve Diaspora's federation. Florian Staudacher (raven24) is currently working on put the federation on its own layer. You can follow the work on the federation part on loomio

Make the code-base modular

One of the things which has held up creation of features is that the fundamental aspects of the software, such as federation, are not yet stable. And if they have to be changed significantly in the future to improve network performance, this can cause features to suddenly stop working, which means that all the effort to create them has been wasted. This happened once already, and it set back Diaspora development by a long way, and it's something that we're keen will not happen again. Therefore, another important task that developers are working on is to make the code-base 'modular': that is, with each element of the code-base in its own discrete 'package'. Once this has been done, and elements such as federation have been separated into their own layers, making big changes to those fundamental parts of the code won't have knock-on effects on other elements such as features.

Create an API

API stands for 'application programming interface'. It gives a structure and language for apps to work on the network. Once this has been created, it will be far easier to create and implement apps for Diaspora. But like all of the fundamental parts of the code, it's crucial that this be absolutely right first time, and so it is taking a long time to achieve this. If you think you can help us with this, please go here (API link).

Data import/export – account migration

Along with respecting individuals' privacy, having the ability to choose where your personal data are stored was one of Diaspora's founding principles. Two years down the line, it has yet to be implemented. There is an ongoing discussion about how best to implement proper migration of data so that people can easily move from one pod to another. This again is an extremely complex issue, and important to get it absolutely right. There are important considerations regarding identity theft, and how to make absolutely sure that it is impossible for a person to 'spoof' someone else's identity and thus get all their private data migrated to the spoofer's pod under false pretenses. If you think you can help us create this feature, please go here (migration link).

Make it simple to set up a pod

Although the installation and maintenance of a Diaspora pod has been made a lot simpler over the past two years, it is still quite a technical challenge for the average user. However, teams have been working on 'packaging' the software so that the process of installation becomes more or less 'point-and-click'. Progress has been made on this for a number of operating systems, including some on free web space, such as Heroku, but there are many other operating systems to go. If you think you can help us with this, please go here (packaging link).

Make Diaspora compatible with other open networks

At the moment Diaspora is run by bespoke software, written from the ground up with elements taken from other open-source projects, with its own communication protocols. The idea of making Diaspora compatible with other open-source, privacy-respecting networks has been raised a number of times, and this has also been the subject of a long-running discussion. However, the main problem with this is that as yet there is no obvious contender as a 'standard' protocol among open-source networks. If we chose one before this happens, Diaspora could end up the loser when another standard emerges (being the Betamax of open-source networks). Recently, a few protocols, such as Tent, have emerged which may meet these needs, and as soon as one of these emerges as a likely standard, it may well be adopted by Diaspora, along with other networks. Sean Tilley and others have been in discussion with the people behind Tent and some of the other emerging protocols, and also with other free networks, to try to establish which of the protocols is going to meet the needs of the most networks and therefore which should be adopted. If you think you can help us with this, please go here (protocol link).

Features

Once the federation code has been stabilised and put into a separate 'layer', and an API has been created, it will be a lot easier to create features and apps for Diaspora. It doesn't make sense to put lots of effort into creating slick features until the funcdamental code is more stable, as changes to this code in the future could break all the features. If you'd like to help create a particular feature, go to Github

Features which are frequently requested include:

Photo albums

The plan will be to create photos albums, which may include features such as:

  • Tagging users in photos
  • Comments/likes on individual photos or complete album
  • Slideshow/full-screen view
  • Hi-res uploads
  • Editing of photos/albums

Groups / Events

Groups and events are both important means of organising communication. We certainly plan to implement them in the future, but both will only be useful if federation of data between pods is reliable and instantaneous, and this hasn't been achieved yet. See 'Federation' above.

Shared calendars

Again, an important feature which relies utterly on federation, and so can't be introduced yet.

Instant messaging

Discussions are currently taking place on the best protocols to use for instant messaging, and the best means of implementing this feature within Diaspora. See https://www.loomio.org/discussions/3678 for more details.

Video conferencing

It may also be possible to implement video conferencing as part of or alongside instant messaging.

Apps for iOS and Android

Much energy went into creating apps for mobile devices in the early days of the project, and some alpha-version apps for Android still exist. However, it was decided that it would be better to create a mobile version of Diaspora which worked really well and was easy to use on mobile devices. We think our mobile site is good enough that there isn't a need for an app for each mobile device, and hope you agree.

Privacy

Privacy is at the heart of Diaspora, and as such we always want to make it possible for users to be as private as they like, and to know that their personal data are secure.

Encryption

One means of ensuring privacy is through the encryption of data. This includes encryption of data stored by pods, encryption between peer and server (i.e. between user and pod), and encryption of notification emails. There are complex technical issues to sort out in order to make this work, especially in a decentralised system

Have separate public and private bios in profile

Some users have requested separate biographies in their profile, one to be shown to people in their aspects, and the other to be shown to others.

'Public to Diaspora' / pod-only posting

This is a much-requested feature. In fact it is technically impossible to make it 100% safe, since everyone (even Google) could set up it's own pod and receive all the messages that are published "public to diaspora". So having this option would probably give the users a wrong sense of how their privacy actually looks. A different thing is the "pod-only posting", because the pod could easily control that the message never leaves the pod to another pod or search engine. Nevertheless it is not the spirit of Diaspora to communicate only on one pod. Discussion about whether or not these features should be implemented (and how) are still going on.

Functionality

Comment likes

One of the most common questions in Diaspora is 'Why can't I like comments?' Comment likes were available for a long time, but had to be removed as Diaspora started increasing in size, because for some reason on larger pods they were massively increasing the size of the databases and causing the larger pods to slow down. It's definitely part of Diaspora's plans to have comment likes again, but it can only be done once this database problem has been solved.

More connected services (G+, Libertree etc.)

We'd like to enabled our community members to connect with more services. When Google+ launched, its API was read-only, which meant it was not possible for external apps to connect with it [NB: is this still the case?]. However, as and when it is possible to link Diaspora with other services and networks, and as and when developer time is available, we'll hook up with more services. If you'd like to help us make this happen with any particular service or network, drop in to Github. [link]

OpenGraph image thumbnails

This would be a nice thing to implement, and is something we'll look into.

Single-post view

The current single-post view is going to disappear some time soon. The vase majority of people hated it when it was introduced and, even though I think it's a good idea in principle, it was never completed (the work on it became [Makr.io](https://www.makr.io/) and it's not really fit for purpose as it is - for example if there's a lot of text and a photo the text obliterates the photo. It has no way of reacting to different types of post. At the moment a number of options for single-post view are being designed, and it shouldn't be too long before one or more are introduced. It's possible the current single-post view will be retained as an option, but as reaction to it was so overwhelmingly negative and it's never been perfected, I suspect it will be dropped completely. (Discussion on Loomio https://www.loomio.org/discussions/2110)

Aggregation of reshares

It would be great if we could find a way to aggregate multiple reshares in the stream, and perhaps the comments made on those reshares. However, this would need to work from the query which generates the stream, and this is not currently an easy thing to do. A feature like this might have to wait until various elements of the stream generation have been rewritten.

Preview of comments and private messages

Our post preview feature, introduced in version 0.1.0.0, has been one of the most popular features. It would be great to introduce a similar preview feature for comments and private messages, and we hope this will happen in the future.

UI toolbar to format text

Along with being able to see a WYSIWYG preview of your post, some people have asked for a formatting toolbar so that formatting can be added at the touch of a button rather than having to manually use Markdown code.

Allowing use of HTML in posts

Some people have requested that it be made possible to use full HTML markup in posts rather than the more limited Markdown. There are dangers in this – for example, some people might go completely over-board and your stream could end up being a vile mess of colours, fonts and images. At the moment, Markdown works well for most purposes. We might consider introducing HTML support at some point in the future, but currently it is not a priority and no decision has been made on whether it would be desirable.

Customisation of stream

There have been requests to be able to customise the stream, so that it can be viewed, for example, chronologically by time of posting (the current view), or chronologically by latest activity on each post (the view used in My Activity), and that it would be possible to 'pin' certain posts to keep them at the top of the stream. Another feature sometimes requested is to be able to colour-code posts. Each of these are things we'd like to introduce,

Filtering stream by tag

At the moment, you can show a stream filtered to show only posts containing a certain tag, by clicking '#Followed tags' in the side-bar and then on the tag you want to see. However, there is no way of filtering *out* certain tags. This would be good to have, but is not a critical feature and not likely to make it to the top of the list of priorities any time soon. However, if you'd like to work on it, let us know.

Filtering stream by language

There's no real technically feasible means of filtering automatically by language. Language recognition by software is not an easy thing to achieve – and tends to be expensive. Suggestions have been made that people should include a tag for the language they're posting in. However, there's no way of making people do this, and it wouldn't really be a desirable thing to do in any case. It has been discussed before, but there doesn't seem to be any way of achieving it which is within the means of Diaspora. If you're really bothered when people post in languages you don't speak, you can block those posters.

Editing posts

This is another very frequently requested feature. However, there are some good reasons not to allow editing of posts once the post has been made. One of these is that if someone comments on a post and it is then changed, that is unfair on the commenter, as it may make their comment look irrelevant, ridiculous or offensive. Another is that, in a decentralised network, it can lead to different versions of a post existing on different pods. [NB: is this true? I didn't think this was how federation worked, but I've heard it said by reliable sources] For these reasons, it's unlikely that editing of posts will be allowed in Diaspora. Especially now with the preview function, it's easy to edit and perfect your post, including formatting, *before* you post it. If you really need to change it once you have posted it, copy the text of your post, delete the post, and then correct and repost it. A related thing which is often requested is to be able to change the visibility of a post from aspects only to public. However, here there are important privacy considerations: anyone who has commented on the post when it was limited will suddenly find that their comment, made to a limited audience, is now visible to the entire internet without their knowledge or approval. For this reason, it isn't desirable to add this option. Again, if you want to make a limited post public, copy/delete/repost as public.

Being able to reshare non-public posts

Just as above with changing a post from limited to public, there are important privacy considerations in this: if someone made a post limited, they did it because they only wanted the people they have placed into their aspects to see the post. They don't want all your contacts to be able to see it as well – if they did, they'd have made it public. This is why it is not possible to reshare a non-public post. It is possible, of course, to copy the text and post it yourself, but this isn't really in the spirit of respecting each community member's privacy.

@-mention members in comments

This is something that we really want to introduce. However, first we need to decide who can be @-mentioned in a comment. Can you mention anyone in your contacts list? Or anyone who has taken part in the conversation? Or both? There are technical considerations for each of these options. We're trying to work out the best way forward, and what will work best for our community.

Subscribe/unsubscribe button

It would be great to introduce something like this so users can follow a discussion without posting on it, or stop receiving notifications after posting on discussion. Hopefully we'll be able to introduce it in the future.

Improve search

There are two elements to this issue: be able easily to identify the person you're looking for, and getting all possible results to a search from all pods. On the first, there have been calls to be able for example to search for people by real name, but part of respecting privacy is allowing each person to reveal exactly as much or as little about themselves as they want. Each person can use whatever name they want, whether this is their real name or simply 'X'. If you know someone and want to connect with them on Diaspora but can't find them using a search, one thing you could do is to give them your Diapsora handle so that they can find you easily. On the second point, this is a federation issue and should improve as we sort out the remaining problems with federation between pods.

Don't know enough about these/not sure what to say

RSA keys needed

Ability to run pods as Tor hidden services

Consistent UI and terminology across all areas

Threaded comments

Customizable UI themes

Unmasking of shortened URLs, replacing with full, actual link

Using audio/video tags for embedding media

The option to receive plain text email notifications

Non-JS website version