Big congratulations and thanks to everyone who’s been part of the way diaspora* has grown as a community-run project over the past 12 months.
I thought now would be a good time to start discussing where we feel the project, the software and the network should be in 12 months’ time, and how we might set about getting there.
Look forward to reading everyone’s thoughts on this, the exciting next step in the journey.
Note: This discussion was imported from Loomio. Click here to view the original discussion.
If the federation works like a charm, my main wish for the software is to have a working and function-complete API and to be able to connect “Clients” to a Pod without giving the account-password to the Client (like Twitter does).
This way we can have Desktop-Clients that integrate with the OS, mobile Clients that can be used to easily share photos from mobile phones and also Bots and statistic-software, that connects via API to the account. All the things that made me like Twitter should be possible with Diaspora, too - so it will be (in my Opinion) the best of all social Networks.
Another big thing is the “reshare” function. I don’t like to scroll over 5 reshares of the same post made right at the same time.
There could be a “fulltext-quote”-reshare with option to comment on the post, or a “just reshare”-function that will reshare the post like twitter does with tweets. That way you will se a post only one time in your stream, even if it’s reshared multiple times by people that are in your stream.
API is defo needed within the next 12 months - sooner better Also another huge thing we need is proper export of data - we are promising users data ownership yet offer currently less complete data export than Facebook. Not good.
Chat? Optional imho, but important.
Something I would love D* to push towards would be a direct competitor to Tumblr. Lots of blogs are hosted on Tumblr and D* could do that so much better. And it’s so much closer to doing that than outdoing Facebook or Twitter - who are difficult to compete with.
We have almost everything Tumblr has. To run a blog people would really only need two things;
Possibility to customize the tags filtered by default on their profile. For example, if I run a blog, I could tag my blog posts with #blog and have only those by default immediately seen on my profile. This way I could combine my social account AND have a clean blog.
Allow anonymous commenting to the blog posts. This should of course be opt-in per user. Should these be federated? Possibly.
IMHO diaspora* could make the killer blogging engine due to the powerful social features and post formatting.
To compete with Tumblr D* should implement more comprehensive control over the posting. I.e. markdown is not enough by any means. One needs to be able to use HTML/CSS to a good extent. Blogger service allows that. Creating an HTML WYSIWYG editor for that in addition to raw HTML/CSS would be an extra bonus to compete with.
I’ve always viewed Diaspora not as some FB+Twitter clone which encourages single sentence status updates and brain dead reshares, but as a platform to post something meaningful. Giving more control over the formatting for posting helps that lot.
Do what we can to accelerate the decentralization of the network
For that second point, registration on joindiaspora and diasp.org are now closed, but we can do better, in term of communication but also in term of make the installation easier and the software lighter (make an smooth image for raspberry pi would be awesome).
Big features needed:
chat
account migration
Improvements needed:
Smoother and auto refresh stream and notifications
Mention in comment
Factorization of reshares
If we deal correctly with all these points, we are golden.
priority: add support for groups and events.
Groups are hampered by issues by federation, but I would suggest we implement them anyway and restrict them to members of the same pod. This would make diaspora a viable channel of communication for organisations, who could setup pods for their own members, and thus grow the network. (discussion here: https://www.loomio.org/discussions/4547)
subscribe to rss feeds (possibly as an aspect)? done soon this would help us build on the google reader closure exodus.
I’d like to focus on the ‘bigger picture’ rather than talk about individual features.
The things to aim for over the next year (although perhaps not all of them will be completely achievable in this time) are:
Start to move the network from being ‘centralised’ on a few very large pods to a more even distribution of many more small pods.
Get diaspora talking with other networks and apps.
1. increase number of pods
I think what we need to do is make the setting up and running of a pod far easier and a more desirable thing to do, and encourage people to set up their own pod, either for their own use or as an open pod.
To do this, I think we’ll need to achieve the following:
make installation and maintenance far easier for the non-technical user (I suggest creating a GUI for both installation and maintenance).
also have really clear information about what is needed to run a pod (I suggest a guide to prospective podmins on the project site)
improve federation to the point where the experience on a single-user pod is practically the same (if not completely the same) as on a very large pod (no more ‘empty stream syndrome’)
enable full account migration, so people can move pod at will, and encourage people to try the smaller pods or to set up their own
encourage people to have a go at running a pod, perhaps with a pledge that if you want to try, we’ll have people who will help and support you every step of the way (we’ll need volunteers for this)
2. get diaspora talking to other networks and apps
discuss with other decentralised networks what will be needed to develop a shared protocol
create an API!
I think these areas need to be made priorities for development. I appreciate that they are more complex and harder to solve than coding a specific feature, for example, and so developers might not be immediately attracted to them, but I think this is where our new ability to raise money can come in: we could fund dedicated working groups to solve each of these areas: federation, API, packaging, migration and so on.
I think a wiki page should be created to summarize the discussion, and to prioritize things. It should also be reflected by milestones in GitHub’s bugtracker. Or is it too obvious?
Diaspora is awesome! Just to get that out of the way
But here is my opinion (for what its worth).
API - Requirement.
Without any means of developing 3rd party apps for mobile and desktop, D* functionality is very limited. G+; Twitter; Fakebook… All simple to use, and easily navigable via a mobile platform.
Chat - Requirement.
Inter Pod connectivity (read federation) is great, but communication is all important. Without the ability to instantly message/chat/voice/video, D* is akin to a microblogging platform. Its social, don’t get me wrong, but other platforms are streaming ahead. D* is lagging, both developmentally and user uptake.
Ease of use - Requirement.
While I understand the decision to use markdown in posts, it is hampering the abilities of new users. To most n00b’s, Markdown is akin to programming. It looks like gobbledy gook to those who don’t understand it. Also, it seems that the standard mantra is “Read the tutorials”. That seems a little counter productive. It forces people to learn something foreign to them. While it makes D* a little more heavy, I personally would like to see something like a cut down version of TinyMCE implemented. It will cut down the learning curve by upwards of 70% (guestimate).
Pod Themes - Would be nice.
Running a pod is great, but being able to give your pod the “Personal Touch” would be nice. Nothing too fancy, but changing the colour schemes and swapping icons here and there would give each pod a distinct “Flavour” just like Linux.
User Selectable Themes - Would be nice.
Being able to personalize your experience is fun. It makes your account, truly your own. But I think limiting it to your profile page would be best, so as not to interfere with the rest of D*.
Blogging - Would be nice.
Blogging is a great outlet for people. Having a user selectable “Public”/“Private” blog in place of the current activity view on a user profile would really be great. I know I would use it as an outlet for when i have news.
You can already access majority of D* functionality via API-like stuff. And I know what I’m saying.
Chat would be nice to have but I don’t think it’s priority. Direct messages will do for a while.
NO. Stop it NOW. Don’t oversimplify/dumbify things just to please new users. Using Markdown is not a necessity but it’s useful for more advanced users. BTW, what’s wrong with little bit of learning/RT(F)T attitude? I think it’s good to point people to resources with which they can educate themselves.
Pod themes? Why not user themes? (ProTip: look for Stylish Firefox addon).
You create your custom style. People see you D* page and see it styled. You see everything styled.
What’s wrong with aspects? If you want limited/public/private functionality create Aspect called Private and add nobody to it.
Really. API-Like stuff. You might want to dig a little deeper. Look at most of the discussions on here. Almost half of them come back to the API.
I imagine your a programmer. Messages will do for us, but for new users, chat is a requirement.
I disagree wholeheartedly. If you want markdown, have it, but whats wrong with combining the two? Make it user selectible via the profile. My grandmother will never learn markdown, but has some small experience with Office, therefore TinyMCE or similar will be fine.
Stylish relies on the end user installing, and knowing how to use it. Not only that, but it also relies on FireFox and derivatives. What about the majority who are still using Chrome and IE?
I know they do. And I agree that a good API is a must-have. (API-like hacks are not as good as a real solution so point for you).
Yes I am. OK, but haven’t I said that DM will do for a while? I didn’t negate the importance of chat. I just don’t think it’s the most important feature we need.
Point for you. Maybe make the markup language selectable for individual posts instead? In JSON it could be like {“markup”: “markdown”/“tinymce”} or something like this to enable clients to easily detect what they have to parse. I think we can find some common ground here.
It was just a suggestion. I put it like this: basic styling (background image/color, font colors etc.) can be done via web UI. This is for users like Average Joe. More experienced users would have the option to upload custom CSS stylesheet to pod and style every element. What do you think about it?
I suppose you agree with me on points 5. and 6 (you made no comments about them). Does Private aspect solves the issue you had in mind?
I think the issue of themes is kinda moot. These are things that would be NICE to have, more than a major requirement.
As for your final point about private aspects :
Yes, again, its fine. It would do the job. But its not about “doing the job”. Its about being intuative, and providing means of communication for the end user. Some people post blogs, others use twitter. Some post in pictures like Tumblr.
Im not saying we should be everything to everyone, but a blog functionality within the public profile view would be adventageous. Otherwise its just another view of the main stream. Im thinking of giving another means of “personalising” the way your data is shown to your ‘followers’. If that makes sense.
Do you have any vision how this should be done? Maybe have another top bar tab? It would then be “Stream”, “My Activity” and “Blog”. And should the blog-posts be separated from normal activity-posts?
I think it would be a good idea to have discussions of specific features on separate threads, and keep this one for discussion of where we believe diaspora* should be headed over the next 12 months. Otherwise this thread will get bogged down in details and its purpose will be lost. Would that be all right with you?
Automatic push to stream would be nice. Just not regular pull from client but some kind of push system, for example http://socket.io/ type of thing. Don’t need to send the stream itself as a push, just enough to tell the client when to pull.
