Current and future development: Difference between revisions

From diaspora* project wiki
(Add link to loomio)
(→‎Editing posts: added more information; updated some existing information; organized)
 
(7 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Speculative}}
{{Speculative}}


We thought it would be useful write a bit about what's going on with diaspora* development, as another major update, version 0.2.0.0, has recently been released and warmly welcomed. In the last couple of major releases we've been able to launch features, such as post previews, a new single-post view and embedding of more media, that people have been asking about for ages. However far more work than that has been going on to improve diaspora*'s performance in ways which might not be immediately visible. It can be 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.
== Introduction ==


Needless to say, if you think you can help in any way with the development of diaspora*, please make yourself known on [https://github.com/diaspora/diaspora/issues?page=1&state=open GitHub]. Use the search bar at the top of GitHub to see if there is an existing open issue for the element you'd like to help develop. There is a specific 'newcomer' tag which marks projects suitable for someone who's new to diaspora*'s code; these can be found [https://github.com/diaspora/diaspora/issues?labels=newcomer&page=1&state=open here]. You are going to find links to Loomio on this page. Loomio is the tool we use to debate and take decisions about the project. Everyone is welcome to join, so if you'd like to help us improve diaspora*, [https://www.loomio.org/groups/194 join us there].
We often get asked about the development of diaspora*, and when a particular feature will be available. Hopefully this article is help to answer your questions about development!


Sean Tilley (deadsuperhero@joindiaspora.com) started [https://www.joindiaspora.com/posts/2636466 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.
The development of diaspora*'s software is done entirely by volunteers, so what gets developed is really dependent on what those developers want to work on. We do have a core team of developers – themselves volunteers – who help other developers by reviewing their code and giving them some direction. The core developers concentrate their own development work on code which will improve diaspora*'s architecture and performance in ways which might not be immediately visible. It can be 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 aspects of development.


First there are the fundamental parts of the software that make the diaspora* network operate.
Needless to say, if you think you can help in any way with the development of diaspora*, please make yourself known in [https://github.com/diaspora/diaspora/issues?page=1&state=open our GitHub repo]. Use the search bar at the top of GitHub to see if there is an existing open issue for the element you'd like to help develop. There is a specific "newcomer" label which marks projects suitable for someone who's new to diaspora*'s code; these can be found [https://github.com/diaspora/diaspora/issues?labels=newcomer&page=1&state=open here].
 
You are going to find links to [https://discourse.diasporafoundation.org/ Discourse] on this page. Discourse is the tool we use to discuss the future direction of the project, and to vote on proposals concerning development. Everyone is welcome to join this discussion, so if you'd like to help us improve diaspora*, read [https://wiki.diasporafoundation.org/Discussion_and_support our article on using the Discourse instance] and join us there.


== Fundamental code ==
== Fundamental code ==
First there are the fundamental parts of the software that make the diaspora* network operate.


=== Sort out federation ===
=== Sort out federation ===
If you don't yet know what 'federation' refers to, it's the sharing of data between pods in a decentralized 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. The code which runs federation [https://github.com/Raven24/diaspora-federation has been exported] by Florian Staudacher (raven24). It now has to be integrated inside diaspora* core. You can follow the work on this [https://www.loomio.org/discussions/3704 on Loomio].
'''[[Federation]]''' refers to the sharing of data between pods in a distributed network such as diaspora*. 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. However, this has been without doubt the most complex problem facing diaspora*'s developers, and as yet the issues have not been fully solved. An awful lot of work has been going on behind the scenes to improve diaspora*'s federation.


We would love to set up a working group to crack the problems associated with federation in a network of diaspora*'s size. If you'd like to help, make yourself known on that Loomio discussion.
'''Update: a [https://github.com/diaspora/diaspora_federation major overhaul of the way federation works in diaspora*] was released as part of version 0.6.0.0.''' This dramatically improved federation performance. diaspora* release 0.6.3.0 and newer has support to receive entities with this protocol, but was still sending entities with an older protocol. Since diaspora* release 0.7.0.0 (August 2017) this protocol is fully supported.
 
We would love to set up a working group to continue solving the problems associated with federation in a network of diaspora*'s size. If you'd like to help, make yourself known in [https://discourse.diasporafoundation.org/c/federation the Federation category on Discourse].


=== Make the code-base modular ===
=== 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.
One of the things which has held up creation of features is that some fundamental parts of the software 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 has happened before, and it set back diaspora* development by a long way, so it's something that we're very 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 software in its own discrete "package." Once this has been done, making big changes to those fundamental parts of the code won't have adverse effects on other elements such as features.


=== Create an API ===
=== 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 released, 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. At the moment, the official API is still [https://github.com/diaspora/diaspora/pull/4554 under development], but you can look at [https://github.com/marekjm/diaspy diaspy], an unofficial diaspora* API written in python which is under development.
API stands for "application programming interface." It gives a structure and language for apps to work on the network. Once this has been released, 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.
 
Of course, being an open-source project, anyone can develop things for diaspora*, and there is an unofficial diaspora* API called [https://github.com/marekjm/diaspy diaspy], which is written in Python.
 
For the official API, [https://diaspora.github.io/api-documentation/ specification draft is available on GitHub]; the [https://discourse.diasporafoundation.org/t/request-for-comments-api-specification-draft/550 corresponding discussion thread can be found on discourse].


=== Data import/export – account migration ===
=== 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 [https://www.loomio.org/discussions/1653 ongoing discussion] about how best to implement proper migration of data so that people can easily move from one pod to another. Feel free to join in the discussion. 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 pretences.
Along with respecting individuals' privacy, having the ability to choose where your personal data are stored was one of diaspora*'s founding principles. This feature is currently being worked on by [https://joindiaspora.com/tags/senyadiasporaaccountmigration Senya]'''. The first part of the feature was merged into diaspora* version 0.7.0.0. It is still missing UI and support for user data archive import which is expected to be done in 0.8.0.0.
 
=== 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.  


There is a [https://www.loomio.org/groups/282 Loomio group] dedicated to this task.
=== Make it simple to set up and run a pod ===
If you'd like to take part, please join in that discussion to contact others who are working on this.
Although the installation and maintenance of a diaspora* pod has been made a lot simpler over the past three 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.


=== Make diaspora* compatible with other open networks ===
=== 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. Placing federation code into its own layer is the first step in that direction.
diaspora* uses its own [[Federation]] protocol which makes it compatible with any other project supporting this protocol. Currently, the [http://friendica.com/ Friendica] network and [https://hubzilla.org/hubzilla/ Hubzilla] are already compatible with diaspora*'s protocol.


== Features ==
== Features ==


If you'd like to help create features, go to [https://github.com/diaspora/diaspora/issues?labels=feature GitHub].
If you'd like to help create features, go to [https://github.com/diaspora/diaspora/issues?labels=feature our GitHub repo].


Features which are frequently requested include:
Features which are frequently requested include:


=== Photo albums ===
=== Photo albums ===
There have been requests to create photos albums, which may include features such as:
There have been many requests to create photos albums, which may include features such as:
* Tagging users in photos
* Tagging users in photos
* Comments/likes on individual photos or complete album
* Comments/likes on individual photos or complete album
Line 48: Line 55:
* Editing of photos/albums
* Editing of photos/albums


There are ongoing discussions about which approach to photos will be best in diaspora*, and whether albums of some form or another approach, such as using #tags to group photos, will be best. You can follow the discussion [https://www.loomio.org/d/sfI0k7mv/organising-photos on Loomio]
'''Update: We have decided that [https://discourse.diasporafoundation.org/t/organising-photos/253/26 using diaspora*'s system of #tags to group photos] will be best.''' The next step is to work out how best to implement this. There are some proposals, such as [https://github.com/diaspora/diaspora/issues/3904#issuecomment-236886058 this one].


=== Groups / Events ===
=== Groups / Events ===
Groups and events are both important means of organizing communication. We would certainly 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. You can read some Loomio discussions about [https://www.loomio.org/discussions/4547 groups] and [https://www.loomio.org/discussions/4546 events].
Groups and events are both important means of organizing communication. We would certainly to implement them in the future, but both will only be useful if federation of data between pods is reliable and instantaneous.
 
You can read more about these features in the Discourse discussions about [https://discourse.diasporafoundation.org/t/add-support-for-groups-in-diaspora/208 groups] and [https://discourse.diasporafoundation.org/t/add-support-for-events-in-diaspora/207 events].


=== Shared calendars ===
=== Shared calendars ===
Again, an important feature which relies utterly on federation, and so can't be introduced yet.
As above.


=== Instant messaging ===
=== Chat / 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 this discussion] for more details.
After much long discussion and several false starts, prototype instant chat, based on the XMPP protocol has recently been developed. '''Update: This is currently being developed using Prosody as the XMPP server.'''
If you'd like to help create this, please say so on that discussion.
 
To find out more, or if you'd like to help create this feature, see [https://discourse.diasporafoundation.org/t/implement-realtime-chat-possibly-using-xmpp/189 this discussion].


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


=== Apps for iOS and Android ===
=== 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.
Much energy from community members went into creating apps for mobile devices in the early days of the project, and some 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. This mobile site is getting better all the time.
 
If you do decide to use an app to access your diaspora* account, get reviews on it from people you trust, and check that it is still being actively developed, before installing it.


== Privacy ==
== 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.
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 at all times.


===Encryption===
===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, and encryption of data stored on pods, for example, would be likely to have an adverse impact on performance. [https://www.loomio.org/discussions/4892 Loomio discussion]
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. Currently all traffic between pods in diaspora* is encrypted, but these instances mentioned above (apart from email notifications) are not encrypted. There are complex technical issues to sort out in order to make this work, especially in a distributed system, and encryption of data stored on pods, for example, would be likely to have an adverse impact on performance.  
 
Find out more in [https://discourse.diasporafoundation.org/t/encryption-in-diaspora/216 this discussion].


===Have separate public and private bios in profile===
===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.
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. There are currently no plans to implement this, but if you would like to have a go at creating this function, we'd like to hear from you.
There are no plans to implement this, but if anyone would like to have a go at creating this function, they are more than welcome.
Since version 0.6.0.0 users can optionally make their extended profile details public.
 
==="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 their own pod and receive all messages published as "public to diaspora*." So having this option would give users a false sense of privacy. For this reason, "public to diaspora* only" will not be implemented.
 
It would be a different matter to allow posts to be visible only to members of the same pod, because a pod could prevent "public to this pod" messages from leaving to another pod (and, potentially, search engines). Nevertheless it is not the spirit of diaspora* to communicate only on one pod. You can, of course, if you are part of a pod which is being run for a community or interest group, add everyone on that pod to an appropriate aspect and then post just to that aspect. In that way, everyone on the pod, and only those people, will see your posts.


==='Public to diaspora*' / pod-only posting===
There is a detailed [http://schub.io/blog/2016/12/02/why-unlimited-limited-posts-are-not-a-thing-on-diaspora.html text that describes why "public within diaspora*" does not work] and will therefore presumably never be implemented.
This is a much-requested feature. In fact it is technically impossible to make it 100% safe, since everyone (even Google) could set up their own pod and receive all messages published "public to diaspora*." So having this option would probably give users a false sense of privacy. A different matter is "pod-only posting," because a pod could prevent "public to this pod" messages from leaving 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) is still going on.


==Functionality==
==Functionality==


===Comment likes===
===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 those pods (and therefore the whole network, as other pods continually tried to communicate with the affected pods) to slow down. It's definitely part of diaspora*'s plans to have comment likes again, but it can't happen while there are still such huge pods. You want comment likes back? Set up your own pod and leave joindiaspora.com!
One of the most common questions in diaspora* is "Why can't I like comments?" Comment likes were available when diaspora* first launched, but had to be removed as the network started increasing in size, because the likes on larger pods they were massively increasing the size of the databases and causing those pods (and therefore the whole network, as other pods continually tried to communicate with the affected pods) to slow down. It's definitely part of diaspora*'s plans to have comment likes again, but it can't happen while there are still such huge pods unless this problem is solved. We're working on ways to reduce the load on the biggest pods. One of the best ways to do this is to reduce the size of those huge pods, so if you want to help improve diaspora*'s performance and are registered with one of the biggest pods, do consider moving your account to a smaller pod.


===More connected services (G+, Libertree etc.)===
===More connected services (G+, Libertree etc.)===
We'd like to enable 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. However, as and when it becomes 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.
You can currently connect your diaspora* account with Facebook, Tumblr, Twitter and WordPress, and we'd like to enable 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. However, as and when it becomes 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.
 
===OpenGraph image thumbnails===
This function has been created by one of our designers since the first draft of this article was written, and was released as part of 0.2.0.0. There's still some work to do, and you can follow its progress [https://github.com/diaspora/diaspora/pull/4215 here].
 
===Single-post view===
This has, at long last, been completely revamped in 0.2.0.0. It was one of the most-requested changes in the 18 months since the 'beta' single-post view was introduced. However, diaspora*' code had changed so much in that time that it required a lot of work to create a more usable single-post view. It was a great piece of collaborative design and coding – you can see the design discussion [https://www.loomio.org/discussions/2110 here] and the coding work [https://github.com/diaspora/diaspora/pull/4410 here].


===Aggregation of reshares===
===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. If you'd like to help with this, post on the [https://github.com/diaspora/diaspora/issues/4219 GitHub issue].
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. If you'd like to help with this, post on the [https://github.com/diaspora/diaspora/issues/4219 GitHub issue].
===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===
===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.
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 overboard and your stream could end up being an unpleasant mess of colors, 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===
===Customization 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 that may be useful to introduce, but depend on someone to step forward and develop them.
There have been requests to be able to customize 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 color-code posts. Each of these are things that may be useful to introduce, but depend on someone to step forward and create them.


===Filtering stream by tag===
===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.
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.
There's an [https://www.loomio.org/discussions/3256 existing discussion] about this.
There's an [https://discourse.diasporafoundation.org/t/feature-tag-filtering-old-diaspora-pistos-feature/182 existing discussion] about this.


===Filtering stream by language===
===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.
Language recognition by software is not an easy thing to achieve. There is an open [https://github.com/diaspora/diaspora/issues/3513 GitHub ticket] for this issue.
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 ignore those posters.


===Editing posts===
===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. 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.
Related discussions:
 
* [https://github.com/diaspora/diaspora/issues/1762 Github]
* [https://discourse.diasporafoundation.org/t/feature-proposal-editing-of-posts/394 Discourse]
 
Basic edit features have been added to the protocol. See diaspora_federation [https://github.com/diaspora/diaspora_federation/pull/94 pull request 94].
 
There is a [https://www.bountysource.com/issues/196897-user-should-be-able-to-edit-posts bounty] that will be awarded to the developer who implements this feature.
 
There is currently no indication that someone is working on implementing this feature.
 
==== Concerns ====
 
A few people are concerned that posts will be edited to intentionally distort context. More people (based on comment support) think that this will not be a significant problem, and that it is mostly overcome by quoting what you are addressing. Further, there is [https://pod.geraspora.de/posts/659d27e014640136aed8101b0e8ace24 reportedly] consensus among developers that an edit feature must include revision history, which also addresses this concern.
 
==== Related ====
 
While editing posts is not possible, it's easy to edit and perfect your post, including formatting, using the preview function ''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. It can also be useful to have a diaspora folder on your computer where you save each post before publishing it. That makes it much easier to republish something if it uses markdown.
 
A related feature 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===
===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.
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.
If you want to do this, it's best to ask the person who originally posted if they're happy for you to 'reshare' it in this way.
===@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, as well as privacy considerations. We're trying to work out the best way forward, and what will work best for our community. [https://www.loomio.org/discussions/2079 Loomio discussion].


===Subscribe/unsubscribe button===
If you want to do this, it's best to ask the person who originally posted if they're happy for you to "reshare" it in this way.
This has sometimes been requested so users can follow a discussion without posting on it, or stop receiving notifications after posting on discussion. At the moment, the 'like' feature is the way to follow a discussion, but there may be ways to improve this functionality. We're open to suggestions!


===Improve search===
===Improve search===
There are many ways to improve the search function in diaspora*.
There are many ways to improve the search function in diaspora*.


There are two essentials when searching for a person: to be able easily to identify the person you're looking for, and getting all possible results to a search from all pods.  
There are two essentials when searching for a person:
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' or a symbol. 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 diaspora* ID (which looks like an email address) so that they can find you easily.
 
The second point, receiving all possible results for your search, is a federation issue and should improve as we sort out the remaining problems with federation between pods.
# To be able easily to identify the person you're looking for;
Search actually allows simply searching for a person (name or ID) or a tag. One possibility could be enabling search using boolean expressions: for example, "person && !#nsfw" would return every post written by this person except ones containing the #nsfw tag, or "Sean Tilley || #diaspora" would return every post written by Sean or containing the #diaspora tag. [https://www.loomio.org/discussions/1193 Loomio discussion]
# 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. No one has to use their real name ''anywhere'' in diaspora*; each person can use whatever name they want, whether this is their real name or simply "X" or a symbol. 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 diaspora* ID (which looks like an email address) so that they can find you easily.
 
The second point receiving all possible results for your search is a federation issue and should improve as we [https://discourse.diasporafoundation.org/t/improving-federation/190 sort out the remaining problems] with federation between pods.
 
The search function in diaspora* currently allows searching for a person (by name or ID) or a tag. One possibility could be enabling search using Boolean expressions: for example, "person && !#nsfw" would return every post written by this person except ones containing the #nsfw tag, or "Fred Bloggs || #diaspora" would return every post written by Fred or containing the #diaspora tag. If implementing something like this, it would be useful to provide a UI so that users don't have to remember the Boolean codes.




[[Category:Drafts]]
[[Category:Drafts]]
­
­

Latest revision as of 00:08, 21 March 2019

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.

Introduction

We often get asked about the development of diaspora*, and when a particular feature will be available. Hopefully this article is help to answer your questions about development!

The development of diaspora*'s software is done entirely by volunteers, so what gets developed is really dependent on what those developers want to work on. We do have a core team of developers – themselves volunteers – who help other developers by reviewing their code and giving them some direction. The core developers concentrate their own development work on code which will improve diaspora*'s architecture and performance in ways which might not be immediately visible. It can be 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 aspects of development.

Needless to say, if you think you can help in any way with the development of diaspora*, please make yourself known in our GitHub repo. Use the search bar at the top of GitHub to see if there is an existing open issue for the element you'd like to help develop. There is a specific "newcomer" label which marks projects suitable for someone who's new to diaspora*'s code; these can be found here.

You are going to find links to Discourse on this page. Discourse is the tool we use to discuss the future direction of the project, and to vote on proposals concerning development. Everyone is welcome to join this discussion, so if you'd like to help us improve diaspora*, read our article on using the Discourse instance and join us there.

Fundamental code

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

Sort out federation

Federation refers to the sharing of data between pods in a distributed network such as diaspora*. 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. However, this has been without doubt the most complex problem facing diaspora*'s developers, and as yet the issues have not been fully solved. An awful lot of work has been going on behind the scenes to improve diaspora*'s federation.

Update: a major overhaul of the way federation works in diaspora* was released as part of version 0.6.0.0. This dramatically improved federation performance. diaspora* release 0.6.3.0 and newer has support to receive entities with this protocol, but was still sending entities with an older protocol. Since diaspora* release 0.7.0.0 (August 2017) this protocol is fully supported.

We would love to set up a working group to continue solving the problems associated with federation in a network of diaspora*'s size. If you'd like to help, make yourself known in the Federation category on Discourse.

Make the code-base modular

One of the things which has held up creation of features is that some fundamental parts of the software 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 has happened before, and it set back diaspora* development by a long way, so it's something that we're very 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 software in its own discrete "package." Once this has been done, making big changes to those fundamental parts of the code won't have adverse 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 released, 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.

Of course, being an open-source project, anyone can develop things for diaspora*, and there is an unofficial diaspora* API called diaspy, which is written in Python.

For the official API, specification draft is available on GitHub; the corresponding discussion thread can be found on discourse.

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. This feature is currently being worked on by Senya. The first part of the feature was merged into diaspora* version 0.7.0.0. It is still missing UI and support for user data archive import which is expected to be done in 0.8.0.0.

Make it simple to set up and run a pod

Although the installation and maintenance of a diaspora* pod has been made a lot simpler over the past three 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.

Make diaspora* compatible with other open networks

diaspora* uses its own Federation protocol which makes it compatible with any other project supporting this protocol. Currently, the Friendica network and Hubzilla are already compatible with diaspora*'s protocol.

Features

If you'd like to help create features, go to our GitHub repo.

Features which are frequently requested include:

Photo albums

There have been many requests 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

Update: We have decided that using diaspora*'s system of #tags to group photos will be best. The next step is to work out how best to implement this. There are some proposals, such as this one.

Groups / Events

Groups and events are both important means of organizing communication. We would certainly to implement them in the future, but both will only be useful if federation of data between pods is reliable and instantaneous.

You can read more about these features in the Discourse discussions about groups and events.

Shared calendars

As above.

Chat / Instant messaging

After much long discussion and several false starts, prototype instant chat, based on the XMPP protocol has recently been developed. Update: This is currently being developed using Prosody as the XMPP server.

To find out more, or if you'd like to help create this feature, see this discussion.

Video conferencing

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

Apps for iOS and Android

Much energy from community members went into creating apps for mobile devices in the early days of the project, and some 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. This mobile site is getting better all the time.

If you do decide to use an app to access your diaspora* account, get reviews on it from people you trust, and check that it is still being actively developed, before installing it.

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 at all times.

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. Currently all traffic between pods in diaspora* is encrypted, but these instances mentioned above (apart from email notifications) are not encrypted. There are complex technical issues to sort out in order to make this work, especially in a distributed system, and encryption of data stored on pods, for example, would be likely to have an adverse impact on performance.

Find out more in this discussion.

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. There are currently no plans to implement this, but if you would like to have a go at creating this function, we'd like to hear from you. Since version 0.6.0.0 users can optionally make their extended profile details public.

"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 their own pod and receive all messages published as "public to diaspora*." So having this option would give users a false sense of privacy. For this reason, "public to diaspora* only" will not be implemented.

It would be a different matter to allow posts to be visible only to members of the same pod, because a pod could prevent "public to this pod" messages from leaving to another pod (and, potentially, search engines). Nevertheless it is not the spirit of diaspora* to communicate only on one pod. You can, of course, if you are part of a pod which is being run for a community or interest group, add everyone on that pod to an appropriate aspect and then post just to that aspect. In that way, everyone on the pod, and only those people, will see your posts.

There is a detailed text that describes why "public within diaspora*" does not work and will therefore presumably never be implemented.

Functionality

Comment likes

One of the most common questions in diaspora* is "Why can't I like comments?" Comment likes were available when diaspora* first launched, but had to be removed as the network started increasing in size, because the likes on larger pods they were massively increasing the size of the databases and causing those pods (and therefore the whole network, as other pods continually tried to communicate with the affected pods) to slow down. It's definitely part of diaspora*'s plans to have comment likes again, but it can't happen while there are still such huge pods unless this problem is solved. We're working on ways to reduce the load on the biggest pods. One of the best ways to do this is to reduce the size of those huge pods, so if you want to help improve diaspora*'s performance and are registered with one of the biggest pods, do consider moving your account to a smaller pod.

More connected services (G+, Libertree etc.)

You can currently connect your diaspora* account with Facebook, Tumblr, Twitter and WordPress, and we'd like to enable 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. However, as and when it becomes 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.

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. If you'd like to help with this, post on the GitHub issue.

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 overboard and your stream could end up being an unpleasant mess of colors, 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.

Customization of stream

There have been requests to be able to customize 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 color-code posts. Each of these are things that may be useful to introduce, but depend on someone to step forward and create them.

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. There's an existing discussion about this.

Filtering stream by language

Language recognition by software is not an easy thing to achieve. There is an open GitHub ticket for this issue.

Editing posts

Related discussions:

Basic edit features have been added to the protocol. See diaspora_federation pull request 94.

There is a bounty that will be awarded to the developer who implements this feature.

There is currently no indication that someone is working on implementing this feature.

Concerns

A few people are concerned that posts will be edited to intentionally distort context. More people (based on comment support) think that this will not be a significant problem, and that it is mostly overcome by quoting what you are addressing. Further, there is reportedly consensus among developers that an edit feature must include revision history, which also addresses this concern.

Related

While editing posts is not possible, it's easy to edit and perfect your post, including formatting, using the preview function 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. It can also be useful to have a diaspora folder on your computer where you save each post before publishing it. That makes it much easier to republish something if it uses markdown.

A related feature 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.

If you want to do this, it's best to ask the person who originally posted if they're happy for you to "reshare" it in this way.

Improve search

There are many ways to improve the search function in diaspora*.

There are two essentials when searching for a person:

  1. To be able easily to identify the person you're looking for;
  2. 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. No one has to use their real name anywhere in diaspora*; each person can use whatever name they want, whether this is their real name or simply "X" or a symbol. 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 diaspora* ID (which looks like an email address) so that they can find you easily.

The second point – receiving all possible results for your search – is a federation issue and should improve as we sort out the remaining problems with federation between pods.

The search function in diaspora* currently allows searching for a person (by name or ID) or a tag. One possibility could be enabling search using Boolean expressions: for example, "person && !#nsfw" would return every post written by this person except ones containing the #nsfw tag, or "Fred Bloggs || #diaspora" would return every post written by Fred or containing the #diaspora tag. If implementing something like this, it would be useful to provide a UI so that users don't have to remember the Boolean codes. ­