This is a discussion pertaining to the attached proposal to work with Tent developers to put Diaspora’s frontend on top of Tent’s backend architecture.
Note: This discussion was imported from Loomio. Click here to view the original discussion.
Proposal: Diaspora, Powered by Tent
The current proposal is here. Part of the point of this proposal is to see what our community thinks of it, and whether or not we would like to make this a part of our project’s future.
Regardless of our involvement or not, the Tent developers are interested in making this port happen as a side-project. The point is not to do all of this refactoring in our own upstream, but rather to develop a working use-case on the side, get it developed to a point of being capable of replacing our current implementation of Diaspora, and in the future, deciding to move to it when Diaspora-Tent is ready.
By working together, we can bridge the Tent community with the Diaspora community, and work towards a higher goal of interoperability and decentralization. It is also worth noting that by switching to Tent’s architecture, Diaspora would finally be capable of delivering on its original promises of things such as:
- Third-party API
- The ability to export your data to a different pod
- The ability to authenticate with Tent apps
- Improvements to how our search system works
- Federation with other web apps that use Tent’s protocol.
It’s also worth noting that the Tent devs are willing to help come up with a strategy for converting existing Diaspora accounts into Tent users, so that all of a user’s posts, messages, and contacts could be converted over to Diaspora-Tent with nothing lost.
Outcome: Motion abstained for now. Thank you all for your feedback. We will explore this again in a few months when a Diaspora-Tent prototype reaches feature parity and tentd can scale to support our pods.
Votes:
- Yes: 3
- Abstain: 3
- No: 7
- Block: 0
Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.
Once we have the federation part of Diaspora properly modularised adding support for Tent is the matter of writing another adapter, no need to maintain two development trees.
I strongly agree with Jonne. Let’s build on what we have, separate the federation layer and make a nice API and we are in a major win. This will just slow things down and make sure that no progress will happen for a longer period of time. A bit like the work on Makr.io which in the end benefited D* in no way.
Working on the federation can happen without needing to redesign the whole application.
@jonnehaß I don’t know whether simply “Writing an adapter” for federation compatibility is the best approach, not to mention that there could be considerable overhead for trying to support multiple protocols. It’s not just our protocol schemas that need to be improved, but also the way our system handles federation internally.
Tent’s reference implementation for federation, an API, and apps is already modularized in Tentd as a gem, and protocol development is done upstream to benefit multiple social applications, including Diaspora-Tent.
Furthermore, the Diaspora-Tent development tree would be maintained by three of the core Tent devs for the interim. Think of it less as “potential upstream” at this point, and more of a “proof-of-concept prototype” to demonstrate that it might be a good design decision, and may incidentally actually work quite well. Sure, the option to move it into our own tree might take some work, but I think the benefits outweigh the effort of moving it over, and we have the benefit of waiting for Diaspora-Tent to properly ripen before even throwing it into our development branch.
I don’t think it’s too soon to think about something like this. It’s something that affects our future, and frankly an active upstream developing all these things could only help the future of our project.
Sean,
Jonne was NOT talking about the adapter like the twitter- or facebook-stuff.
We already discussed adding a “federation layer” here: http://www.loomio.org/discussions/612 and we really should focus on that one before doing anything else. Really. We should.
When that part is done we can focus on what we should use as protocol, but please not before the abstraction is done. If we have a nice abstraction layer, it’s even possible to “play around” with multiple protocols, and that’s what Jonne was talking about.
Honestly, I was thinking about blocking this discussion. Without an abstracted federation, we cannot even say what Diaspora really needs and thus any discussions about that are pointless.
"I don’t think it’s too soon to think about something like this."
All devs do. If you take a look at the messy code we have right now, you’ll understand there is no more brain capacity for this discussion.
@dennisschubert I wasn’t talking about the cross-posting functionality. I meant running adapters for multiple protocols at once. Writing a bunch of protocol bridges that all run at the same time could be cause for significant overhead.
Also, the Diaspora-Tent implementation would be done from the ground up using Tent’s architecture, with Diaspora’s UI on top. It’s a clean start, being done by the Tent developers as a prototype, to demonstrate what the protocol can do. So there would be far less mess than trying to jam Tent’s architecture into our current codebase, which I agree is pretty messy in parts. Once tentd is proven to scale, and Diaspora-Tent has feature parity with Diaspora-current, we can consider officially adopting it in the future.
The API and federation protocol are already documented, and would significantly lower the barrier for anyone wanting to improve the state of federation in Diaspora, not to mention help make good on the project’s original promises.
@seantilley-communitymanager With “prototype” you are talking about the idea @kevinkleinman suggested? Yes, do it if you want to. But that has nothing to do with the work at diaspora-core. And of course all my (and Jonnes, and probably everyone elses) points are against Tent in Diasporas core.
@dennisschubert I’ve cleaned up the proposal document on the wiki to better explain. Sure, at the moment it has little to do with Diaspora-Core, but the idea is that in the future, it will be comparable to Diaspora-Current in terms of features and scalability, and may be something we as a community could adopt into our upstream development.
So in a sense, it has everything to do with Diaspora-Core, as it directly affects the potential future of the project, and would establish a broader community of more developers working together towards the same goal of decentralized social.
@seantilley-communitymanager “in the furute”. Exactly. And we are back at Jonne’s point. 
The way I understand it, this is indeed about building a prototype from the ground up and then seeing if the experience can be applied to Diaspora. I have absolutely nothing against that since in the very least case, Tent is going to have a nice new app.
I suppose the abstration layer stuff can be done by the Diaspora development team simultaneously to the Tent guys building their prototype app. Perhaps we can then link those two pieces together; the clean, modularized Diaspora code and the Tent protocol schemes as used in the prototype. Tent wouldn’t have to be in the core.
Or perhaps when the prototype works better than the current version of Diaspora, we’d just have to move everyone over to Tent and then take over the development of the prototype.
@flaburgan The real question is, if Diaspora-Tent were in every way comparable to Diaspora-Current, but with Tent’s architecture improvements, would we consider adopting the prototype into our upstream development?
What is the real question ?
Can Tent developers try to put the Diaspora interface on their protocol ?
Of course they can, it’s free software !
Will we help them to do that ?
We can answer to their questions, improve our doc and clean our code. But we have no time to build something, a proof of concept or a real new branch.
Will their poc be the new Diaspora ?
Who knows ? They can make a poc, they will learn a lot by doing that. And if the poc is really good, then we will vote. But it will be in months.
The real question is, if Diaspora-Tent were in every way comparable to Diaspora-Current, but with Tent’s architecture improvements, would we consider adopting the prototype into our upstream development?
So, refer to the 3rd question below. We will decide it when we will see the poc
So after playing around with tent-admin and tentd, I’ve discovered that while Tent’s reference implementation(s) do work, they are still somewhat difficult to hack on. However, I find working with the software to be very straightforward and I look forward to at least a philosophical/sharing-ideas partnership with Tent. After playing with tent-admin, there does seem to be a bit of an issue with the way we work and the way Tent works.
For starters, Tent is “more distributed” than DIASPORA. What do I mean by that? Well, each user is responsible for their own tentd, and a (reference) tentd can only serve 1 user at a time. I’m not sure how the shared Tent hosting works, but if they aren’t using anything special I bet it’s just launching new instances of tentd-admin for each user that logs in. This is definitely an unsustainable practice, and IMHO Tent will have to figure out a shared hosting paradigm before the network gets too big. Otherwise, it won’t, leaving Tent to stagnate in the realm of obscure hackerdom and one of the curiosities of the strange social-networking environment our society has created for itself.
That’s why I’d like to see this Loomio thread die, and us continue discussion of a possible DIASPORA/Tent partnership on either the mailing list or somewhere else, because I think the research done from mixing the paradigm of “one server for many users” with Tent’s distributed architecture, and allowing a single pod to function as multiple Tent servers.
This can definitely be done, but will probably require a lot of effort on both our and Tent’s part.