Who is working now on Open Apps Ecosystem?
Bob Haugen PublicSeen by 121Who is working on something now that they think belongs in an Open Apps Ecosystem?
If someone does, he needs to add his action here so anyone can see it. In the FOR NEWCOMMERS column, you have all the documentation you need on "how you can add an action"
What is it?
Where is it?
How can other people get involved?
@bobhaugen , the link https://t.me/joinchat/DHkZFQxtkzCnmWxddNByBA redirect to tg://join?invite=DHkZFQxtkzCnmWxddNByBA which doesn't work.
My current actions are mentioned on the wekan page : https://wekan.indie.host/b/G4LCutYkTJLhSCAtn/open-app-ecosystem
I would like to create a small team of developers (coding people !), so if you're interested get in touch with me.
If you want to join the Kamasi Telegram group, try this link: https://t.me/bhaugen
I would like to create a small team of developers (coding people !)
What would you like them to do? Since we already have at least one small team of developers working on open apps (on the Kamasi project), do you think we might be able to collaborate?
(I think there are probably some other teams working on other related projects, too...)
I would like to create a small team of developers (coding people !), so if you're interested get in touch with me.
Interesting idea. And if so, @bobhaugen 's idea of combining is interesting too.
Is it an Open App Ecosystem team? Or something more separate? And how would projects and who works on what get decided?
I'm working on the solsearch API, server and Drupal clients.
It is a geolocated index for offers and wants listed in (local) community groups.
We will roll it out to all the sites in Community Forge, if they want it.
I need help to present it as an open project, to encourage other groups to participate.
I don't even have a web page for it yet, just the API ( https://app.swaggerhub.com/api/matslats/sol-search/1.0.0 ) on Swagger.
Matthew's call is an interesting case study. I'm thinking about it, also in relationship to the Open Food Network people's thoughts about different needs for different vocabularies, in their case, wanting food specific terminology.
@matthewslater how would this work in these use cases? I.e. how do we make what you have created an open app in an ecosystem?
Mutual Aid Network, which uses Community Forge for their timebank, and Wezer as another app that includes a marketplace with offers and wants. Community Forge will have the new api. Does Wezer need to add the same api? And then how does it work? Is there something else that shows all the aggregated offers and wants from both sources (with the geo-location feature), or would each app show the offers and wants from the other app in addition to its own?
In NRP/OCP we have exchanges in addition to projects/processes/work stuff. Suppose we want to get the exchanges out there in the form of offers and wants using your stuff, so they can be aggregated with other offers and wants. We have an api being built using ValueFlows vocabulary, using graphql, with an rdf based one on the roadmap in the unknown future. How would we proceed?
I feel like I need an architectural diagram. :)
Hi Lynn
The SolSearch is general purpose which means it has no vocabulary built in, only keyword searches. It is also not translatable, assuming that you know the local terms for whatever it is you are searching for.
It is not possible for a person to submit items to solsearch directly, it is merely an index of content on other platforms, and it does not store user identities. To contact the person who posted the item, solsearch redirects the user back to the original post.
@matthewslater how would this work in these use cases? I.e. how do we make what you have created an open app in an ecosystem?
- Mutual Aid Network, which uses Community Forge for their timebank, and Wezer as another app that includes a marketplace with offers and wants. Community Forge will have the new api. Does Wezer need to add the same api? And then how does it work? Is there something else that shows all the aggregated offers and wants from both sources (with the geo-location feature), or would each app show the offers and wants from the other app in addition to its own?
We can enable in Hamlets (used by Dane County TB) very soon, but Wezer would need to implement the simple API and build its own search interface.
Each client is a platform like drupal or Odoo, and every time the data changes it updates the SolSearch Index. To browse the index, each platform needs to build a search interface and display the results.
A mobile phone app could search the index, but it would need the apikey of a platform in order to submit items for indexing directly.
- In NRP/OCP we have exchanges in addition to projects/processes/work stuff. Suppose we want to get the exchanges out there in the form of offers and wants using your stuff, so they can be aggregated with other offers and wants. We have an api being built using ValueFlows vocabulary, using graphql, with an rdf based one on the roadmap in the unknown future. How would we proceed?
whenever an 'exchange' wants to be indexed, you just send a REST request to (our) solsearch server.
The API is clear how to do that. You just need an APIkey from Community Forge
I feel like I need an architectural diagram. :)
Sorry I don't feel like drawing one right now.
Thanks @matthewslater , very helpful! Good food for thought about how in general might be the best way for open apps to interact and what open apps should be responsible for.
Sorry I don't feel like drawing one right now.
Didn't mean to imply you should make one, it was just an unnecessary comment to the universe. I'll make one at some point, when we start to better understand how more pieces might fit together.
The idea as I imagine it is described here : https://www.communecter.org/#page.type.projects.id.596d0ef440bb4e83147b23e6.view.detail
and in technical terms here : https://docs.google.com/document/d/1lhDJgyPB1f3zyLz3Zy626GEvxchwks0yDo-aA3LxSRI
@lynnfoster :
I'm working to set up an SSO Identifiant Provider and a common menu for the different apps of the ecosystem. As we though that for beginning we could use Communecter.org for dealing with the working groups, the common menu, the common database and the APIs to communicate with other apps, I can work on this task in collaboration with the Communecter developers team.
If you agree with this way of doing, we need developers to create plugins (addons) on open apps to make the communicate with the API (Communecter's API for a start).
This is a huge work, and I need to be in touch with theses people to build an API capable to communicate well with the plugins of the apps.
@matthewslater :
I you agree with this project, and as I now a little of Community Forge since our session in Genova, we could have a conversation to see how we work to connect CForge to the ecosystem. A Drupal plugin would be wonderful as it could be used to any Drupal projects !
@bobhaugen :
I don't really know how to integrate ValueFlows in the project, maybe we should speak with @tiborkatelbach
I don't really know how to integrate ValueFlows in the project, maybe we should speak with @tiborkatelbach
Don't worry, we'll watch your progress and see if we can figure out a way to interconnect.
We're scheduled to talk with Tibor on Tuesday to figure out how to use his vocabulary mapping system with the ValueFlows vocabulator. If we can get that to work, then maybe we can figure out how to get from there to communicate with different API's.
Great !
Hi Marc,
If you agree with this way of doing, we need developers to create plugins (addons) on open apps to make the communicate with the API (Communecter's API for a start). This is a huge work, and I need to be in touch with theses people to build an API capable to communicate well with the plugins of the apps.
So if I understand, this is what you want to build a team for? I will volunteer to work on apps that I am already involved in and know the code. In general, I'm trying to slowly get out of coding in my life, so I want to work only on things where I can do it much quicker than someone else because I already did work on the original app for example. I also want to minimize having to learn new technologies if I can, getting too old. :) So I realize this is not much help, but maybe a little. :)
I'm working to set up an SSO Identifiant Provider and a common menu for the different apps of the ecosystem. As we though that for beginning we could use Communecter.org for dealing with the working groups, the common menu, the common database and the APIs to communicate with other apps, I can work on this task in collaboration with the Communecter developers team.
I don't know if I agree yet, would have to see how it will work. I am hesitant to create a center inside one of the open apps, I fear people will not see it as independent enough to make connections. All the open apps need to actually be peers in the ecosystem, in my opinion.
SSO is sorely needed, and a common menu can be very useful for groups who use different apps. I would be very hesitant to use Communecter directly though, no matter how good it is. Or are you forking it and taking pieces of the code that will be an independent app just for the open apps ecosystem?
Let's also figure out what would be needed in the common database and how to minimize that.
The discussion with Tibor on Tuesday will be at least partly about api's, can you come to that?
And/or - maybe all the technical participants should be part of a discussion of how to architect the peer to peer connections of open apps, even if just to start. This would be beyond the SSO itself.
I know you are jumping in, which I think is really really really great (did I say how great that is?? :) ), and I'm sorry if I am slowing things down, but I also think we need to consider together some of the main architectural decisions, or it risks not gaining acceptance.
What do you and others think?
want to build a team for?
Yes, we need specialists for each app
Thanks for your proposal to help for the apps you knowcreate a center inside one of the open apps
If we have a common menu, we need a common database to store it. For a start, I suggest to have it on only one server. After, if it works well and people are using it, we could work more to make this database P2P.
We need a platform where people can complete their profile, join groups, be geolocated on a map, have notifications and find other contributors or working groups. Communecter is well designed for managing all that, especially the groups and the relations between them. So I thought it could be the first platform to integrate in the ecosystem. Later, we could add others.
But I agree with you, we could think to create an independent database and software, only for connecting and communicating (via APIs) between the platforms (Communecter as the first one) and the others apps. This software would be the core of the Open App Ecosystem.
Forking Communecter would be a bad idea because we will have difficulties to integrate further enhancements. But Communecter can already communicate threw APIs.
I'm going to change strait away the technical document : https://docs.google.com/document/d/1lhDJgyPB1f3zyLz3Zy626GEvxchwks0yDo-aA3LxSRI/edit
Thanks @lynnfoster for this analyses (tell me what you think about this new proposal), others mustn't hesitate to give their opinion !
If we have a common menu, we need a common database to store it. For a start, I suggest to have it on only one server.
I'm totally fine starting with a common database on one server for things that are ecosystem data, as needed. Ah yes, the money... I am not too worried in the short term, although it is a question for sure as we go forward and grow.... but for later when we have that "problem". :)
@bobhaugen I updated your thread, tell me what you think about that.
I guess the rules to make us work together are :
* If you do an ACTION related to open app ecosystem, add it in the wekan
* This ACTION must be understood in less than 30 sec
* For each ACTION it exists a "GUIDE : How to contribute to the action"
* This GUIDE is really easy to understand and enables anyone to contribute to the ACTION
Is it OK for you all ?
Mostly ok with me, but I don't know how you would tell if "This ACTION [could] be understood in less than 30 sec". I'd make it more like a suggestion, "Please make it as easy to understand as you can." But that's also just a suggestion, do what you will.
@bobhaugen I created a thread about it though. Seemed for me quite good to make everyone agree with it ;)
If I was new to this set of conversations, I would not respond well to all of those MUSTs. Do you understand why?
I don't understand what you mean.
Ah, good, you changed the one that bothered me the most...thank you.
things seem to be heating up in the channel :) +111
as for Communecter, it mustn't be a game breaker but a game builder , or just a brick amongst others.
In the process of buidling things for the french ecosystem working on the commons, We build a "no brand version" which is interesting for trying to step away from any Branding and naming issue. Which, many beleive (so do I ) is a big source of the problem.
Getting a real ecosystem to work out , means :
1 - we (any of our communities) can seemlessly use and benefit 1.1 from each of our features,
1.2 - from any of our open data content and Each communities users decide what is opendata and what is not
2 - we all contribute to a common system (database and/or feature base ) , that grows not only through a common app but by the relations and contributions of each the ecosystems plateform
I won't go into detail, on how we (Communecter) imagined and are doing all this , but it's happening with a few use cases (apps and apis interconnecting ) and will be getting better month after month.
This would be a great call for discussion amongst architects , designer and developpers as you propose @lynnfoster
@funkycram
Our friends at Framasoft have a user DB, that can access a whole list of open source projects , it's part of solution but not all of it , and if I'm not mistaken, they are building an Linux distrib OS based on whyYouNoHost , that only contains open source installed apps , all this because Framasoft doesn't want to host you as a user, and is going for a distributed mainstream system.
Anyone today can do this on his own computer, they are just packaging it conveniantly.
I still undrestand this is not exactly what you have in mind and you want something directly online without a system to install.
If the ecosystem works out, I think the question remains on who serves and pays the service ?
so let's make it a call, with pleasure
I think the question remains on who serves and pays the service ?
Very important question. I think one trend is everybody hosts their own node, and organizations host their own node.
I am not a bigtime blockchain fan, but blockchains pay for hosting and operating the consensus method(s) by transaction fees. We also see more organizations taking responsibility for developing as well as hosting their own systems.
[edit] I missed this question, read too fast:
I still undrestand this is not exactly what you have in mind and you want something directly online without a system to install.
I suspect different people in this group have different things in mind...
Yes, I would like to build an ecosystem for non "geek" people.
Give to everyone the possibility to work without proprietary software.
And link it to a social platform such as Communecter so people can meet each other and make their project being known (and much more !).
I think the question remains on who serves and pays the service ?
Ha ha ! That's an eternal problem. Let's do it, and if many people enjoy it we will ask them to contribute or help us to find resources.
I won't go into detail, on how we (Communecter) imagined and are doing all this , but it's happening with a few use cases (apps and apis interconnecting ) and will be getting better month after month. This would be a great call for discussion amongst architects , designer and developpers
I look forward to learning more of the detail and the use cases!
I'll start a separate discussion....
I think the question remains on who serves and pays the service ?
The question could be : Who makes this job ? Who construct the machines ? (If we think in term of new economical organisation)
This hangout is starting now - to look at Communecter, and talk about vocabulary and interoperability. We'll record it, in case you wanted to join but couldn't.
here's the recording
https://www.youtube.com/watch?v=9Yb5bomm-QE
thanks for joinning @lynnfoster @bobhaugen hope it was clear (and fun ;) )
I highly recommend people watch or at least skim the recording of today's demo. And yes it was fun! :)
We talked about others doing the same thing. Bob and I would volunteer to do one, in maybe 2 weeks. It would be NRP/OCP (brief because it is an app among many, not a linking app), Locecon (still pretty brief, might have some linking possibilities but we don't know), and ValueFlows (meant to create links among apps). If there is time in one session (which there well might be), we could also include the new Kamasi front-end, which also has linking possibilities, if @ivan116 is willing. It right now talks to NRP/OCP but the goal is to make it more independent.
Or if someone else wants to go first, that is good too.
We also talked about where to communicate. I'm dropping some links here for @tiborkatelbach to see if the Communecter vocabulary translation system can handle them. I'll also put them in the Wekan action, and also in https://chat.lescommuns.org/channel/open.apps.ecosystem once I get an account there.
They are from the ValueFlows Vocabulator demo.
* Agents:
* http://valueflows.pythonanywhere.com/vocab/agents/json/
* http://valueflows.pythonanywhere.com/vocab/agents/json-ld/
* Agent Relationships:
* http://valueflows.pythonanywhere.com/vocab/agentrelationships/json/
* http://valueflows.pythonanywhere.com/vocab/agentrelationships/json-ld/
* For a stretch goal, Processes:
* http://valueflows.pythonanywhere.com/vocab/processes/json/
* http://valueflows.pythonanywhere.com/vocab/processes/json-ld/
I need to get the process flows presented in json and json-ld, too, but in the meantime, here's a diagram.
I work on open technology standards-- not directly on any apps, for now. Of course, I think that Open App Ecosystem certainly needs to develop one or more standards (or protocols).
Here are my main recent works-in-progress:
- Modular Organization Terminology
- Peer-to-Peer Digital Networking
- Agreement-Based Governance
- Shared Resource Development and Support System
^ Please note that I'm refactoring my "Conversation for Action" prototype as a component of that "SRDSS" system.
I also have some IMO relevant "back burner" projects including:
[Edit]: My designs are intentionally generic, and some of them probably aren't appropriate for trying to develop an Open App Ecosystem right now. Also, I don't want to "clutter up" the Wekan much.
I may add one or more of the three most fundamental active projects--MOT, P2PDN and ABG-- to the Wekan. It depends on how strictly you want this OAE effort to be focused.
Depending on how important you think vocabularies and protocols are, you might want to call out those parts of your works-in-progress that you think would be useful for those purposes.
@bobhaugen I think you've just found the perfect name for the vocabulary translation module : babelFish !! I loved the explanation :) , That book has been on my list for so long , it's about time I read it .
so babelFish it will be :)
babelFish is a good name, but it's already been trademarked by a specific translation app/platform: https://www.babelfish.com/about-us/
I'm no fan of copyright law (to put it mildly) but I think it'd be prudent to find another name. I could try to help if folks get stuck. Good luck!
https://www.producthunt.com/@erwblo/collections/open-source-alternatives-for-everything
Product Hunt
Open Source Alternatives for Everything by erwin blom - Product Hunt
Free open source alternatives for Medium, Twitter, Slack, GitHub, Trello, Evernote, and more!. Discover 21 curated products like Chart.js 2.0 and Ghost 1.0 about Open Source Alternatives for Everything by erwin blom
@jimwhitescarver would be really interesting to learn how many of those can work together in any integrated way. @ivan116 proposed a bot that could potentially integrate with a bunch of them. Might help...
Yes. Integration of the sources is necessary in my view. Whatever can be done by bots should be. I think the processes should also be integrated with our communications environment. The vision is chatops for everyone.
Perhaps we can try something like that in the Social Ledger Prototype Demo and Trial being discussed in the governance thread.
I suggest I create our demo mattermost team now and we experiment with bots and other integrations to prototype there. We might also consider using gitlab rather than wekan for integration with mattermost etc.
That social ledger project looks very interesting. I am buried until maybe Tuesday, but will try to make time to look at it.
Overall, though, we'll end up with the usual profusion of softwares that don't work well together, although each is wonderful individually: Loomio, RocketChat, Wekan, Communecter, Digilife, and yet another set of software suites for those of us who work with other organizations at the same time (Fair Coop, Sensorica, LearnDeep, Open Coop, P2PFoundation, etc etc etc).
And I don't want any one of those environments to become "the center" and dominate all the others.
If I have anything to do with it that wont happen. Interoperability is key to a viable app ecosystem. Integrations enable interoperation. Standards and frameworks simplify integration. That rocketchat and mattermost both have a degree of slack API compatibility means the branches of our integrations could be more or less agnostic to what is being integrated with. In so far as we can implement a standard API for any tool the can be integrated readily.
Good! A bot or two would be a useful experiment.
here's a starting point to experiment and visualize the open Apps Ecosystem , it might be a way to see who is who and where
https://www.communecter.org/#oae
Every one and anyone can create Organizations, People, Members , Projects and events with a geographic visualisation
I am working on a mindmap of various projects
https://framindmap.org/c/maps/436408/public
and learn about these projects
Hi @christopheparot1 that looks like a useful map - it's funny you know... most people who arrive here are all very keen on building a map ;) - me included! I think it is a valiant aim. But imho it will never be inclusive enough, or up to date enough, or useful enough, unless it is an open map, to which anyone can add, classify, describe and update links... It's great that Greg has made suggestions for your map, but imagine if we could all contribute to the same map... I made the same suggestion about the excellent map at https://kumu.io/DigitalLife/digital-life-collective but I am not sure if that is open for submissions yet..?
A few questions, to all in this group:
Would others here be interested in contributing to an open map? (Suggested title 'OAE related projects' or similar...)
Is there a way we can do that with Framindmap, or is there a better / more suitable tool?
Ideally I would suggest we need to use a tool which allows a collaborative map to be embedded on other sites (and I can't see how to do that with Framindmap!? )e.g. if this was possible I would definitely be us for including it on http://collaborative.tech/
Best
Oli
https://kumu.io/DigitalLife/digital-life-collective is open for submissions https://github.com/DigitalLifeCollective/mapped-projects An easier interface for submissions might be nice.
I suggest a few other projects which you @christopheparot1 (and perhaps all of us) may want to consider for mapping purposes:
* Patchwork
* Beaker Browser
* Holochain
(Those github links may not be the best intro to each project, but it's a way to consistently document their public workspaces)
I think that's what metamaps is for
in fact there allready are a few maps out there maybe @Ishan or @Connor have some idea
https://metamaps.cc/maps/469
But imho it will never be inclusive enough, or up to date enough, or useful enough, unless it is an open map, to which anyone can add, classify, describe and update links... It's great that Greg has made suggestions for your map, but imagine if we could all contribute to the same map...
This discussion about maps (like metamaps and framindmap referenced above) makes me think again about what it might mean to make an open app ecosystem. I think we always need to be open to multiple apps that do basically the same thing, people will have preferences for their specific purposes, technology will continue to march along, etc.
What if in addition to having open maps (the minimum requirement), we have a way that people can publish the data of their choice (for themselves or an organization) once under their control, and the mapping apps that are part of the ecosystem can pick it all up? Some kind of a many-to-many registration structure between agent data and map apps? Lots of architectural issues, I'm aware.... but the more we talk about it all, the more I go down that road.... is the open app ecosystem basically about defining and standardizing the space between apps?
(Sorry if going too far OT)
Hi @lynnfoster @tiborkatelbach thanks for the reminder about Metamaps - is that particular map open i.e. can anyone contribute to it? (I'm awaiting my login for Metamaps). I'm not sure if it can be embedded elsewhere either?... and actually, although I understand the categorization is probably better (deeper) than a standard mindmap, I actually find the map @christopheparot1 made much easier to read ... and imagine beginners would too.
RE "..a way that people can publish the data of their choice (for themselves or an organization) once under their control, and the mapping apps that are part of the ecosystem can pick it all up" I love this idea. It's the future for sure as it fits with the "I own my data" concept... it reminds me of the old FOAF file concept https://en.wikipedia.org/wiki/FOAF_(ontology) I can easily imagine a 'MAPME' RDF file doing exactly what you describe.
But in the short term I still think there is a need for a very simple map, of the kind Christope has started, while we work out how best to define, standardise and encourage utilization of the user-centric "MAPME" version.
I am working on two projects that want to be part of an open apps ecosystem:
* Value Flows, which wants to be a vocabulary and protocols for open apps for economic networks.
* In particular, I am now working on the Vocabulator, a demo for the vocabulary, and plan to make it work with @tiborkatelbach 's vocabulary mapping system.
* A good way for new people to start getting involved is to post something on https://gitter.im/valueflows/welcome or raise an issue on https://github.com/valueflows/valueflows/issues or just say so here.
* If you particularly want to help with the Vocabulator, raise an issue on https://github.com/valueflows/django-vocabulator/issues or say so here.
* I am also helping @lynnfoster and @ivan116 on Kamasi, which wants to be a UI and API covering many open apps.
* If you want to join that one, raise an issue on https://github.com/django-rea/rea-app/issues or just say so here.
Lynn and I have some other projects in motion, and they are open, but probably not good candidates for an open apps ecosystem (they are monolithic platforms). They were precursors and proofs of concept for Value Flows.