Experimentation with Open App Ecosystem

+1 not sure to get the social network part but eager to see more :)
in the meantime ill study react-native-web, didnt know it, but seems promising, I hope it will be easy to migrate a react app to a react-native (web) one

@luandrovieira what are your main goals for functionality specifically for your quilombola village? What do you think people will need or want for that situation?

P.S. Awesome slides! May we use them for OAE when communications are needed?

@ivan116 I haven't personally tested React Native Web yet, but have known about it for a while, and am hoping that it would be a good fit for this use case. For web apps to run SSB and Dat we would have to have another app running on the background. SSB is basically a social network protocol, because is spreads your message to and from your friends (as far as I understand it).

@lynnfoster Please do use them, and let me know if you find any errors or if the information needs an update. From talking and being around the natives I've gathered a few ideas like: transparent watershed management; market for arts, crafts and farm goods; ride sharing... I think the big potential is for applications that deal with local economy and governance, which people aren't even aware of yet.

a wallet to manage social currencies.

Are you familiar with GNU Taler? It's a free code, online payment system, designed to work with any existing currency ($, Euro, BitCoin, anything). Also, I maintain a list of software and platforms for local currency exchanges, and community trading in general, some of which are free code (active projects and abandonware) and might be useful.

FYI There are quite a few existing free code apps for hosting kanban boards on the web.

Hi strypey, yes I knew about all of that, but all those kanban app are an evolution of kanban that does not allow manufacturing or production of means representation.
They are the classic "todo - doing - done" kanban, tailored more for agile development.
What we're developing is a resource flow kind of kanban, where you can follow the resources involved into a plan, and perform any kind of event: production, exchange, consume, use, buy, sell etc
You can read more about this idea here: https://speakerdeck.com/mikorizal/how-everything-is-connected-in-nrp

great project @luandrovieira , if we can help out on the social network part we'de be more than happy , I'll with you here 3 docs going in your direction
OCDB : Open Common Database
https://docs.google.com/drawings/d/1rp0Y0afwZGKw_swkAHMvyNnmyXRM4DgiihvcqaVrITI/edit?usp=drive_web
COPI :
https://docs.google.com/drawings/d/1hvDIRN3u4kvuo6-N7twFrjQ8uidEmXuSzm3dli_JTmg/edit
https://docs.google.com/presentation/d/1efQiAdOt54_XoxJaYZPazxCK0T83jdgdmer-le9NwDY/edit#slide=id.gdd654f576_0_6
sorry they are in french , but pretty self explanatory

Thanks you @tiborkatelbach , nice docs. Actually similar to how I imagined OCDB, which would be formed in a Dat file by aggregating/filtering many SSB resources. The Pi in my mesh network will act as a backup for community data and useful external data (in order to save bandwidth).

we are defeinitly on the same tracks :)
and the decentralized model is much more resilient +1111
we managed to get his in a POC using http, but it's so slow , we wanted to cry
so the same with a DAT, SSB or IPFS is defeinitly the way to go
Thanks you @tiborkatelbach , nice docs. Actually similar to how I imagined OCDB, which would be formed in a Dat file by aggregating/filtering many SSB resources.

That's what we called the COPi Mix
The Pi in my mesh network will act as a backup for community data and useful external data (in order to save bandwidth).

That's what we called the COPi Bank (for storing backups)

I like the name COPi it carries the idea of easy duplication, connectivity, resilience , persistance, and the possibility of running on lowtech
what do you think ?

I like it. Although I'm not sure a Pi would be the best hardware for every scenario.

Just published on #moinho-mesh channel in SSB with a few revisions on the slides.

Pi could also mean : Processing Intelligently :)

Great work ! I don't understand everything as I'm not a developper, but I like the graphic design :D

I'm very interested in all of this! OAE is still one of my few main goals on a digital networking systemic/holistic level. Thanks @luandrovieira for giving OAE such deep thought, and in relation to the inspiring goal of mesh networking in central Brazil. :)

Regarding distributed data processing and hosting, FYI I'm closely involved in the Holochain community. (In fact I've often wondered how to coordinate OAE's goals with Holochain, but I severely lack time to focus on that.) With that in mind, I wonder precisely how the functions of datprotocol, IPFS and SSB compare (and eventually will compare) to Holochain's.

I understand Holochain (which is not fully deployed yet!) to be extremely flexible & scalable for fully p2p distributed applications, potentially including the processing and hosting of data (and databases) in all formats. However, I also understand Holochain to be intentionally designed to handle relatively small data items instead of (for example) the huge multimedia files which BitTorrent, IPFS etc can handle. I think that the Holochain devs are hoping to eventually integrate IPFS (or equivalent functionality), but large multimedia files are currently a very low priority for them.

FYI, I would much prefer for OAE to not be married to any specific system for distributed data processing and hosting! I realize however that depending on many variables, OAE could become (practically and informally) married to a specific system, project and team initially-- mostly for the sake of getting stuff done!-- and then gradually develop a more flexible interface.

I like the idea of getting stuff done in the first place and then see what happens.

We're talking to people at Holochain as well as with @luandrovieira and @ivan116 about SSB and DAT as possible infrastructures for OAE flocks coordinated apps.
Ivan's goal is a set of client apps that would work on many backends.

Hey @gregorycassel I've been hearing a lot about Holochain thru @bobhaugen on SSB, and it does seem promising. To me it looks like a very good solution for a single online storage, which is very different from what I'm expecting with Dat and SSB, which in a community network scenario would deal mostly with community data. A next phase would be to get the community data out, and SSB and Dat may not be the best solution for that, and tech like Holochain and SAFE could play an important role in having a singleton database.

Thanks for your feedback @luandrovieira ! FYI, I wouldn't describe Holochain as a singleton database per community. (In fact, the Holochain core devs often stress that fact that they're not trying to create a single global "source of truth".) Every person in a specific holochain will share one p2p distributed application, but the data (which that app generates) will be created and hosted in a deeply distributed, "localized" way.

Of course the subject is too complex to address concisely in a Loomio comment. There are tons of related Holochain essays & interviews; I could make recommendations if desired.

I like SSB and especially the messaging app Patchwork, but I don't know much about their devs' overall strategy for enabling multi-app functionality such as the OAE vision. (And I know very little about datprotocol so far.)

I imagine that something like Patchwork could probably be made to work with SSB and Holochain, as well as other p2p signaling systems. Likewise for any of the other functions which I've long desired to support in an open app ecosystem.

Thanks for clarifying @gregorycassel I was thinking Holo was something more like SAFE where currencies could run kinda like a blockchain. I'll try to understand it better.

I think we can get very powerful, versatile and creative apps just by combining NodeJS, Data and SSB on a mobile. Something to get currencies and a access to a global web like SAFE are to me the last missing piece. I'm thinking more and more that Holo could also play that role.

I would love some documentation about holochain <3

What is "Patchwork" you are talking about ? The thing to create bridges between all the P2P apps (like holochain and SSB)

Patchwork is a client app for SSB, and only works with SSB.

Our hotlist for OAE infrastructures includes SSB, Holochain, and Solid. I think this stuff can be done on the open Web, but will require a bunch of experiments. Here's a sketch in that direction: How to implement a Conversation for Action ReSTfuly. Might be possible to combine that pattern with Solid.

SSB and Holochain may have lots of advantages because they have worked out a lot of the details of P2P computing. And might be more candidates that should beconsidered. I have not looked much at MaidSafe, and don't understand DAT very well.

Don't we practically get Solid's Linked Data with SSB's type's?

As far as I understand Dat is basically a very intelligently distributed file system. You can use it anywhere you would use a file system.

For my specific case, I'm betting on these two because they can both communicate freely on a layer 2 mesh network, enabling devices to talk in a truly p2p manner.

Makes sense to me.

So if I get it right, we could kind of mix (or it's already mixed) SSB, Holochain, Solid and DAT ? And everything could work together, so we don't need to pick one, we could work with every of these concepts ?

I think @ivan116 's plan for user interface components is to work with different backend technologies. Some of them are compatible with each other, some probably not. So you wouldn't probably mix SSB and Holochain or Solid the same coordinated OAE community, but you could (and I think @luandrovieira wants to) mix SSB and DAT.
But I think Ivan wants the UI components to not care which of them you use, as long it can give him a valueflows graphql API.

But so far this is all talk. We'll see how the first experiments go. Right now Ivan's components only work with Fair Coop's OCP back end, which is not yet decentralized.

By using GraphQL as a middle layer between different protocols (Dat, SSB, Holo) we can easily mix em together. There's no one best protocol for every case, every protocol has it's pros and cons, and GraphQL helps us to unite them in a easy to use API.

I really admire Solid's vision, but I think it's significant parts (Linked Data for example) can be implemented in other protocols.

@luandrovieira I agree with that, if and only if you mean using the same UI components with those different protocols. But SSB assumes everybody in the same network is not only using the SSB protocol but also is using the same network identity. I think Holo also assumes everybody is using the Holochain protocol and I suspect they have other requirements for being in a compatible network (I'm looking into Holo now but don't understand enuf to be able to answer that question in detail).

@luandrovieira I'm curious about how ssb and dat will relate to each other in your architecture? Or are they just 2 different underlying sources?

I'm also curious if graphql can substitute for linked open data, that is can graphql find the data it needs from different endpoints that can be accessed with a url? or something similar to that?

(Sorry for newbie questions! I am using graphql for an api on our software but don't have experience with the client side at all. I use ssb, but only know a little about the way it works; and don't know anything about dat.)

@lynnfoster I'm also very new to all this, compared to a lot of devs, but I've been putting a lot of effort to understand it all. This is all from my limited perspective, but everyday I learn and experiment a little bit, and understand a little bit more.

Like I mentioned in other comments, every protocol has it's strengths. SSB is a gossip protocol which is perfect for efficiently replicating a json log on your social network. It's good for quickly spreading data to people who you personally care for, but since everyone holds a huge json log, is not very good for heavy data. That's where Dat comes in, which is perfect for reading, writing or streaming data chunks (think Torrent + Git). One protocol complements the other.

My first experiment was community-apps-hub. SSB is used to publish to my social network that I have added a new application to App Hub. This message contains a Dat hash as content. With that hash anyone in the network can use Dat to retrieve the heavy apk file which is in my device. There are some problems there, like me having to stay online for my friend to be able to get the file from me. But since I'm planning on using this on a community network, we'll have Raspberries that can read the SSB message and download and store the apk from Dat, so that it's available at all times. We could also use a server in the cloud to do that.

In relation to Linked Data, it's not GraphQL that does that, but SSB. In SSB every message you publish to the network has a type. So in any application I can check a persons profile by filtering the messages with the about type. In the case of my experiment I just published messages with a type new-community-app, and then I create a flumedb plugin to filter them out. Another great thing about SSB is that is gives the user the best offline-first experience possible, since a lot of the data is already stored in the device.

GraphQL provides a declarative interface for the front-end, documentation and a playground. It doesn't care about where your data comes from. It's a middle layer between the server and the UI, that helps you organize your data map. If you're using GraphQL in existing application, and you wanted to test with a p2p stack, you probably wouldn't have to change the front-end, or the types. You would only need to changes the resolvers from a cloud database to a p2p database.

Hope that helps. I've been able to integrate GraphQL with SSB on Android, and am now trying to architect a plugin system in order to re-use our types, so we slowly start building a Linked Data ontology (is that the right term?). Hope to be able to share a working prototype in the coming weeks.

Wow! @luandrovieira you've got a lot more of this done than I expected! That's exciting!

@luandrovieira yes that helps a lot, thanks very much! It all makes sense. I like the way you are working to use the strengths of each technology, that gives a very good way to think about the architecture question. And you are doing it, like Bob said, wow!

Just publish a new release for the Open App mobile seed application. It implements GraphQL subscriptions for SSB gossip, translations, and has a new polished interface. Please install the apk, test it out and give some feedback.

If you're adventurous clone and try playing with it. The repo has been moved to the Open App organization on Github.

@luandrovieira very exciting. I will install it and try it, although it will be in a couple days.... and I've never installed an apk file, so it will be a first... but I'm very much looking forward to seeing where you are going!

It's great see people using the design first, code second approach. This gives you a chance to clarify user needs and map out the functions you'll need to meet them, before getting lost in coding roadblocks. Also means you're less likely to do hours of head-scratching coding, only to find that all along there was an existing back-end that can be re-used (or forked) to meet your needs.