sorry I am not a programmer but I wonder if social networks could allow the developments of extensions, add-ons or plug ins … so the features could keep growing freely … ?? I would like knowing how to express this idea in a more technical language but don’t know how… so I just put this “message in a bottle” just in case…
cheers and thanks
Note: This discussion was imported from Loomio. Click here to view the original discussion.
Anybody can fork diaspora and add features on their own pod. If properly maintained other pods can merge those additions into their fork and so on. If properly developed and meaningful for the majority of our userbase we can pull that code into the main codebase. This is already happening.
I don’t think we’re at a state where we need to restrict to a maintainable feature set and thus throw out otherwise popular features, so I see no need for a formal plugin system. Especially once we got a proper Web-API.
Honestly, it may just be better to develop web apps that make use of a Diaspora API.
The only feature I see to make a usefull usage of a plugin system is commercial Facebook-like applications, to which I’m definitly opposed.
However, it might actually be usefull to extensively document the API and the core code’s file to make the code easier to understand for the newcommers like me.
thanks for sharing well I don’t have a clue on programming that’s why I was just truing to share the idea… so not sure on what implications would have been able to have extensions and if it was technicallly feasible … but what I mainly would like seeing is having lots of controls over settings. for example I have posted another post related to “features” like for example
having the chance to set scheduled times to participate in a group or community … or for example been able to join groups of interests … etc…
in few words having far more power and features than the ones that fb offers … hope it makes sense…
I thought allowing people to develop extensions would lead to that but my technical ignorance on the subject does not allow me to expose the things correctly …
Thanks and cheers,
I do like the idea of plug-ins, because it seems like it would be easier for developers to add features, and podmins could decide which plug-ins they wanted to install based upon their whims and/or the demands of their users. This is how Friendica works.
I’ll admit, however, that I am unfamiliar with how D*'s codebase works, so I’ll defer to those who have more experience in these things.
Brent and I have the same idea: forking D* allows developers to add features in a “hardcoded” way. Creating a plug-in system, podmins can freely add and share their own feature, without adding a line of code manually
The only two problem - I suppose - is to think what should happen when you remove a plugin and how to create a decentralized plugin system.
I think, we should clarify this point to make sure we talk about the same thing.
To me, plugins are not the same than extensions. I feel like plugins are much like facebook’s applications : something provided by third parties that the user can install or not. Thing I’m completely against.
Extensions are more like Wikipedia extensions : installed by the admin of the pod to add functionnalities. It seems to be pretty what gems are doing in rails. However, it might be a good idea to let some gems be facultative and let the admin choose which one install or not. But this is much more a deployment problem than a code core’s.
Anyway, in that last sense, I totally agree !
@augier Yes, I was thinking of extensions installed by the podmin, not the user. I don’t know why you’re against third-party apps, though.
Because I fear third-parties come with uncontrollable rights restrictions and non-free contents.
@augier I am not an expert on these things but I guess people could have the option to accept or not (install or not) acquire or not. use or not… or look for free alternatives third party apps… or extensions or whatever is called … is a matter of having optiosn in order to have access to more and more ways to control the way you manage the communities or share the information or set interactions via social networks…
hope it makes sense…
regards to all and thanks for participating on discussions on proposals or ideas… its exciting and promising !
Well this discussion is becoming a little bit political. Here my point : sometimes, choice is not sufficient. Economic studies proved it. For exemple, the market is not self-regulated by pure and perfect competition. It would require people to be informed of a huge amount of informations. It’s simply impossible and utopic.
In our case, people daily accepts ToS without even reading them, thought it is legal contract. E.g : Facebook is the owner of every little thing posted on their network. And very few people are aware of that. There is no choice when you don’t have all the informations. And ToS don’t provide these information as soon as people don’t even read them.
I’m strongly opposed to third-party because I think it is a wide opened door to overindulgences with people’s rights.
right I think I catch your point… but I wonder if in the future… would it be a way to control what sort of third-party stuff could be developed for an opens source application or platform ?? I mean, a way to filter the commercial implications or lack of privacy etc… but alwyas allowing others to develop things that could (eventually) would grow up (modularity) a platform…
otherwhise the developers of diaspora should try keep “developing” teh features that the community keep requiring …
I will try to expose my ideas a bit clearer later on … but I think this issue is interesting …
personally, I have tried to expose some features that I would like seeing in a social network but not sure if diaspora developres would ever consider on focusing on it (everybody have different needs or ways in which they would like controlling the way they share with others… ) is like in teh “real life” isn’t it ??
anyway have to be away now … would keep looking at the feed-backs and discussions …
PS: by the way, even though is not related to the issue of extensions or apps etc…) but I would like to know why fb makes difference between “groups” and “communities” this gets on my nerves I have tried to set a group in fb then someone else suggested me a community page instead… I don’t understand the differences and is affecting the fact that I have to keep posting in both groups or pages since not sure which one would be better… as far as I have seen teh features related to share information are exactly the same… (I don’t see substantial differences… do you ??) this topic should be part of another sort of discussions I know
but for example I was trying to expose a feature I would like seeing about been able to meet groups (groups able to meet up or join other groups) I have nto seen this in fb (would this be considered a feature ?? is this something that could be done as a third-part app ? or should it be part of the diaspora platform itself ?? sorry for my ignorance on this issues but I need to expose these sort of needs … it would be great if social networks would offer more and more options related to way we manage interaction adn share information …
hope it makes sense…
cheers … and thanks !
Actually, the only way to control the developped third-parties is to adopt Apple’s strategy : centralized repo, comunity code review, ToS approbation which more or less (rather more than less…) contrary to D*'s undertakings…
Currently, the problem of D* developement is less the complexity (there’s a lot a documentation on rails and the community on IRC is very present) than the amount of active developpers (30 declared for the last release).
Up for this topic. Recently we talked about customizations for diaspora*. @denschub said that he “would love to have some customization discussions”. I wanted to raise a topic for this, but I saw there is this one, so I guess it’s fine to just continue it here.
Redmine has some plugin system and I think we can reuse some of their ideas. For example we can have a Gemfile.local file, that is not tracked by git, but that allows to include custom gems to the diaspora* installation. By having this we could make gems that would change some of diaspora* features and that could be included by podmins on their decision. For example, we could create a gem that changes @-out-of-the-link to @-in-the-link rendering for mention as we discussed here.
That would still conflict with the Gemfile.lock which is tracked by git (so we can use --deployment for production installations). I simply changed the Gemfile for my pod (and I also removed gems there, that wouldn’t be possible with Gemfile.local either), so I think that’s not a problem for a bit more advanced podmins.
No, simply no … you would need to create a gem that hooks in so many places and even manipulate javascript, that would be a really ugly hackish gem (and probably break with every change made in the code about mentions or anything near it). It would be much easier for podmins to just change the code (and that already isn’t easy for that @-topic). We already discussed to make it an option for users here, and I still think that it isn’t worth the added complexity (same for a setting for podmins, but a podwide setting wouldn’t help users when they don’t like it the same way as the podmins like it).
So the only thing I maybe would do for the @-topic (if really needed), is adding a css class to the @, so people can style it with a userstyle, if they really want to. (But that’s off-topic here)
I found Wagons project. It’s a wrapping for Rails Engines which purpose is to help building plugin systems for Rails applications. It doesn’t look very maintained recently, though it doesn’t look very complicated either. We could possibly try to build a plugin system for diaspora* using that and even if it doesn’t get updated at the upstream I guess we could handle our own fork.
Opinions?
No commit for 2 years, no significant number of stars/forks, insignificant number of users (22901 downloads as of now on rubygems.org), no rails 5 support and the fact that rails 5 changed the way engines works tell me this is something we should either tackle on our own or not do it at all. Using that thing as a basis feels like a really bad idea.
Okay, then we need something similar anyway. Maybe develop an alternative looking at this code as reference where possible.
Here is another idea on this topic.
There is an e-commerce Rails-based system called Spree.
The installation flow of Spree based on gems and Gemfile.
With some simplifications, the installation of Spree is done by:
rails new app
cd app
echo "gem 'spree'" >> Gemfile
bundle install
After that you run some Rails generators:
rails g spree:install --user_class=Spree::User
And after that you have a working application installation.
So basically Spree itself - is a Rails Engine. And being mounted to an empty Rails app it turns it to a webshop without any additional configuration.
So I think that this idea could work for diaspora app as well. If we turn all current diaspora app functionality to a Rails Engine we could use it both with an empty Rails application which would have the same result as installing vanilla diaspora now, and with a modified Rails application. The latter would allow to make tweaks and install some possible extensions for those who want that, without modifying diaspora app (engine) and therefore without a need for rebasing the changes on updates, etc. And if somebody wants to add an extension from a gem, the extension is added to a local Gemfile.