To me, we will be able to release diaspora* as 1.x when it will be possible for a non-techy person to have his own pod. That means the following points have to be easy:
Installation
Upgrade
Backup
Moderation
Performance (a pod of 10 users should run nicely with 1GB Ram)
I have several ideas about what can be done to improve those points, I don’t know if this thread is the place to discuss them on detail. There is at least one issue about admin task I opened a while ago: https://github.com/diaspora/diaspora/issues/4800
It is. This is specifically its purpose, so you can go on
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.
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.
I have lost count of the years I have been waiting for this core feature.
Five, at most
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 ?
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.
0.6.0.0 and 0.7.0.0 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 0.8.0.0 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
