Requirements for a 1.x.y.z release

It is. This is specifically its purpose, so you can go on :wink:

This thread is general and I like it, I’d like to agree with everyone what should be included in 1.x. To decide about the “big picture”. How we specifically solve each point should be discussed on other threads to avoid pollute this one.

1.x means diaspora* is ready to be used by the world, so, as said in my previous comment, I think the focus for 1.x should be “allow a non-techy person to have his own pod”. Admin features are at this point more important to me than user features, that means, I don’t think any user feature (event, group, chat…) should block 1.x.

The backup point is here because we know that hard drive can crash so it was aim to avoid private key lost.

The backup point is here because we know that hard drive can crash so it was aim to avoid private key lost.

So, this should better be automatic, than administrator-driven.

Where did you see I wanted them administrator-driven and not automatic? :wink:

My personal list is more like

  • Seed migration
  • API
  • Chat (in a usable state)
  • Groups/Events
  • Federation 2.0
  • Redesign

ordered by importance. Especially seed migration was one of the core promises that we still couldn’t deliver, releasing a 1.0 without it seems wrong. The federation point is about an iteration or redesign of the federation protocol with better stability, resilience and new standards in mind.

Federation can be interresting, indeed. Maybe you could start a discussion on what improvement you’d see in a Federation 2.0 ?

Does each one justifies a release by itself to you or all of these, or… ?

ACK @ Jonne.
That’s also the list I had in mind.

The critical things for me are, sort of in order of importance:

  • Seed migration, which should be simple for the end-user.
  • API.
  • Performance: more reliable federation, and more economical with system resources.
  • Installation and maintenance of pods should be simple for the end-user, not requiring much specialist knowledge.

What constitutes an acceptable level of performance improvement or an acceptably simple installation/maintenance is a matter of debate.

Chat, groups and events, while important to a successful social network in the longer term, I would not personally consider necessary to v1.x.

Seed migration - Even in its most basic form of simply re-creating my aspects and contacts - not worried about old posts, just allow me to move pods!

I have lost count of the years I have been waiting for this core feature.

I have lost count of the years I have been waiting for this core feature.

Five, at most :stuck_out_tongue:

Ok, what is missing for a seed migration ? @jhass : what system do you have in mind for a feature like thins ? Would it take the form of a button “migrate my account to another pod” in the parameters section ?

I wrote up this once.

Nice. Though, I don’t think it would really justify a 1.0 release if the user had to manually backup/import its data. As thae API is currently being develop, I can suggest the migration fonctionnality to be the first feature of it ? This way, a migration could simply take the form of an OAuth application installed on the old account that will be in charge of importing the whole account into tha new pod ?

I like to add that IMHO, an API wouldn’t be sufficient to justify a 1.0 release because I mainly see that work as a very long-term work over multiple release, one little step at a time.

No, I don’t think we should expose things like close account and fetching the private key over the API. That approach also has the huge downside of not going to work if the original pod goes offline. The archive approach can work as a backup you can restore anywhere.

And of course the API would need to reach a somewhat stable state first. After all these points are not “hit any and we’re good” but “should all most likely included”.

like close account and fetching the private key over the API.

I’ve never intended to expose the close account feature via the API, but about the private key, tha mecanism can stay unchanged from what you described, except that the user does not have to fetch the archive himself in all cases. The archive can be exchanged complitely encrypted between the pods. I’m not sure I see why it would be less secure than the user fetching the archive himself and then uploading it.

That you don’t see how potentially exposing a high risk feature to all third party clients due to potential bugs in the authorization layer is not so much of a good idea if it can be avoided, is a bit sad.

But anyway, we’re getting horrendously out of scope of this discussion, there has been quite some previous talk, please continue there.

“should all most likely included”

indeed. The four items I listed are those I consider essential to have been implemented in a fully working way before v1.0 is considered. and have been released since this thread was open, and if we look @jhass list again, we can check several items!

  • The seed migration is on his way, and the feature should be completely delivered in thanks to @comradesenya.
  • @denschub recently talked about the API in the 0.7 release live stream. I don’t know how you see the future on that point?
  • Chat still has to be polished
  • Groups didn’t see any work at the moment
  • The support for events now landed in the federation layer. There is still a lot of work to do in diaspora*
  • Federation 2.0 has been released, @supertux88 does it match Jonne’s description quoted above?
  • 0.6 brought a new design I’m happy with, there is still room for improvements but the current state seems ok to me so the redesign task can be seen as done

Congratulations everybody!

1 Like

So, I still feel it is valuable to share between us how we see the future of the project and what diaspora* 1.0 could be. So here is my vision, and I would love to see you sharing yours with me and the rest of the community here.

I divide my thinking in three distinct parts which are of course linked, but which all focus on very different things because the point of view is different.

  • The first part is the users point of view. Here, I’m focusing on the value diaspora* can bring to the users. To sum up, nice features and nice UX. To be able to share and find interesting content with other users.
  • The second part is the podmins. How can their life be easy as pod maintainers. Installation, update, backup, moderation, etc.
  • The last part is the network. Because I’d like the UX of diaspora* to be as similar as possible whatever the pod used. And I’d like diaspora* to be able to scale.

So, with that in mind, where should be set the goal for a 1.0 diaspora* release in my opinion? The good news is, not that far. Because in my mind, 1.0 doesn’t mean “feature complete”, it means “solid foundations”.

For the users, I honestly think the features available are already great. It would be nice to re-add likes on comment, and I deeply think the “custom stream based on advanced search” could be a killer-feature. I guess pictures albums also deserve to be put in “share and find interesting content”, and a stable XMPP chat could also be there.

With that we are far away of what Facebook allows users to do, but I don’t think this should be a blocker. There will always be haters saying “wat, you releasing 1.0 n’ don’t even have a group feature? This project definitely iz a fail”. But eh, for those kind of person, 1.0 would never be good enough.

The reality is, diaspora* is already very stable in production. Thousands of persons use it daily without problems, they don’t think they are using a beta software, it is not a 0.X project anymore from a user point of view. What we still have to do though, is to improve UX on already existing features because there is room for improvements. To sum up: keep a small scope, but ship something great.

On the opposite, there is still work to do for the podmins. The software is stable and the minor updates are easy to do. But installation and update have to be way more easier. A good inspiration here is what gitlab is doing. Their tech stack is the exact same than ours (ruby, rails, redis, sidekiq, postgres, etc). They allows installation of everything with a single “full-stack platform-specific package” (See omnibus-gitlab), and an apt upgrade is enough to update, with automatic backup and rollback if something goes wrong. Very easy and inspiring.

Another point where the life of podmins should be made easier: dealing with spam. This can be very time consuming, and a podmin doesn’t have GUI option at the moment to block an external user, delete many reported messages at the same time, etc. Which brings me to the last point:

The network itself. Wow. What a huge amount of progress we recently did on that part, thanks to @supertux88, @denschub and @comradesenya. I’m so amazed that I want to say another thank you once again. With the federation 2.0, I feel like we’re really close to what we can expect for diaspora 1.0* from a federation point of view. I would list in the missing features the “remote following tags” which is IMO more important than the users discovery (as I observe that diaspora* users are more looking for content than contact). Linked to the podmin point, there is also work to do about how to deal with evil users and evil pod (I’m not talking only about the protocol itself in that third point, but about how the network is living and scaling). And linked to the user point, it also feels important to me to make the user experience painless across the federation. Global links is a good example of that. A remote follow button would also be nice.

So, here is my vision about what the project needs to be released as 1.0. What’s yours? :smiley:

1 Like

I think that post and comment edit support and API is a must have for the 1.0 release. It just frustrates me the most: why I can’t edit my messages and why can’t I have a decent mobile application? These are highly frustrating things which can’t be a part of serious release, because it won’t feel as something complete. Also, API can enable so much new interesting use cases that it what is the solid foundation for diaspora growth (no surprise it is the most financed issue on bountysource).

XMPP integration, groups, Mastodon/GnuSocial intercommunication are very important features IMO, and would be nice to have them at 1.0 release, but if we can’t do that, that’s fine.

So I guess that if we manage to implement API and post/comment edit support we’re ready to release 1.0.