I think this is a great idea! However, instead of starting with the technology, could we start with the user needs?

For example, although I try and run as much FLOSS stuff as possible, my current sticking points are:

1. Calendar
2. Group (workplace) chat
3. Kanban-style to-do boards

Personally, I'd like to see a Sandstorm instance for social.coop but, again, let's start with what people want/need!

Indeed, starting with members' needs is a good approach! Definitely feel free to comment with a type of service you need rather than a specific software.

This also brings up the question: what is social.coop's mission? Do we want to help members to "de-googlify" ourselves and go for a full suite of alternative web apps, or do we take the "social" in our name more literally and focus on social networking?...

How about we start a poll (which allows members to add options) for 2-3 weeks - start with your suggested types of software and let people add (I hadn't thought of Kanban - I use Trello all the time, would be great to migrate off it!).

I think starting we needs is the way to go.

Great opening thread by the way @mayel !

I'd start with the 'co-op' part of our name and focus on technologies for co-operation :)

I would echo Doug's comments almost verbatim. The top priority should be allowing people to communicate and coordinate. I'd love to have a social.coop email address!

However, in the interest of undermining my own point, the one specific capacity I was looking for and didn't see was some kind of online LaTeX service. I've been thinking for a while that the way to break the .doc and .docx stranglehold on documents may not be LibreOffice, but rather, ditching the word-processing paradigm entirely.

I personally like using Markdown for basic word processing (check out hackmd) but LaTeX could be worth having too (I wonder how many people use it? is it mostly in Academia?) I'll add it to the list! Fortunately there's ShareLaTeX which looks like a very mature project (with collaboration built in)

Yeah, I do an awful lot with markdown, too, which is why I suggested to @horatiotrobinson that he include gitit. That lets you go straight from markdown to PDF, via LaTeX, with the click of a mouse. But, it's written in Haskell, which doesn't integrate nicely with Ruby. And more to the point, some folks will need more fine-grained detail, which only LaTeX itself can give.

Hey @steve7!

(posting this updated version here because I had only discussed this topic briefly on Mastodon, and microblogging streams are difficult to track and piece ideas together)

I did take a look at gitit, and it's probably an excellent tool for personal use. However from the point of view of the org when you're offering a service for a number of users, technical ability of staff being capable of maintaining the software is a rather important concern. gitit is written in Haskell, which is a very interesting and powerful functional programming language. However, Haskell is also not the most popular of programming languages, Haskell is not the easiest code to read for 90%+ of mortal programmers who are used to imperative programming languages, and competent Haskell talent is scarce to come by. All that means that however good the software may be, it may be too hard or too costly to maintain (in terms of either money or person power) when compared to other available solutions. Thankfully, a number of other very decent potential FOSS solutions exist that are less costly to maintain, more familiar to the average programmer, and more compatible with the tools that Social.coop already has in place.

For example, I had suggested taking a look at a Gollum-rails wiki package, which is written in Ruby and available under the AGPL 3.0 licence.
Turns out that two services that social.coop already uses -namely Mastodon and Loomio- are also written in Ruby (using the Ruby on Rails framework) and are also available under the AGPL 3.0 licence.

Additionally, the Gollum-rails package is a glue package that allows for using the Gollum wiki tool. Gollum is very mature, well understood software that powers the wiki tools at Github, used by millions of their users daily.

All of which means that those three tools are not only the least costly to use and maintain, they also present the least of technical integration problems, and the least legal compatibility problems. (exactly zero legal compatibility problems to boot)

It would be interesting if others could take a look at these things and verify that I'm not overlooking something. But in my mind, unless somebody comes up with something astonishingly better, it's a pretty straightforward situation.

Yeah, the Haskell part is too bad. Gollum compares quite well to gitit, with one notable exception: it doesn't export to PDF. That's not a dealbreaker, but it is disappointing. Now, I did discover a Ruby wrapper for pandoc, alphabetum (not to be confused with the font of the same name), that might allow Gollum to do just that. I don't know how hard that would be.

Of course, it's also possible I'm the only one who cares about exporting to PDF, and everyone just wants a wiki to be a wiki.

Exporting to PDF is a perfectly reasonable need and a function that I'm sure many users would like to have. It's also fortunately a function that's very easy to add to any other Wiki, and there are a number of ways of exporting to PDF independently of the Wiki engine of choice. Take for example gitprint, which takes Github-flavoured markdown as input and generates clean PDF output from that.

https://gitprint.com/jquery/jquery/blob/master/README.md

If your work requires a different type of input or output formatting that can probably be worked on as well.

I didn't know Alphabetum's PandocRuby but it seems pretty good and it shouldn't be hard to integrate, or provide a separate PDF generation function (analogous to gitprint) to work in tandem with any Wiki that can generate output in one of those document formats. That probably means any modern Wiki.
Were you thinking of any document formats in particular, Steve?

There's also wkhtmltopdf which uses the webkit engine to convert a webpage to PDF. I used it for a project recently, it's really convenient as you can stick it in front of any web app regardless of stack, and you can customised the output using a print media stylesheet.

Well, for myself, I was thinking markdown to PDF. HTML to PDF is a low priority, though I'm sure some folks would like to have it. Gitprint seems cool, but I can't find any documentation about how it works.

I only brought up gitprint as one of a number of possible tools (Mayel suggested another one). gitprint doesn't do much else but rendering markdown to PDF. Anyway, Alphabetum's PandocEuby, gitprint, or wkhtmltopdf, it's certain that we're capable of exporting to PDF taking input from practically any modern wiki that is able to produce a known format such as markdown or html. Guaranteed.
Here's the gitprint source code in case it's of interest
https://github.com/adamburmister/gitprint.com

OK, that makes me feel better.

To swing this back around to the original question, it seems to me that the natural first step is to install one of the so-called "meta-platforms," which I think is a misnomer. Nextcloud seems like the natural choice to me. (Nothing against Sandstorm, but Nextcloud looks more polished and cohesive.) It comes with a lot of what people would expect from an online office suite: word processing, a calendar, an email interface, and quite a bit more. Plenty of other things on the list look useful/cool, but this would take us the longest distance in a single step.

Another thought that's been bouncing around my brain today... If even a significant portion of these ideas were implemented, we could host a whole variety of new platform co-ops. The podcasting capacity would work for Taru's audio publishing idea. Riot with Jitsi would work for my remote interpreting idea. There are probably dozens more we can't even see yet. That calls to mind a phrase the Indianos use to describe themselves: "a community WITH businesses, not a community OF businesses."

And that might be where @ntnsndr 's idea of an international, federated umbrella co-op could come in. If we could get the incorporation step out of the way for start-up platform co-ops, then the only hurdles to clear are the ones we set up: the principles of cooperation and free software.

That might be the ultimate service.

As you know, I fully support this and I am eager to contribute (financially, at least) towards this becoming a reality. Also, I agree with @dougbelshaw when he says we should begin by assessing member needs before doing anything... Once we nail that, we can try our hand at expanding towards new areas of interest.
Count on me for this! :)

As for email though, while there is plenty of email server & webmail software, there is no easy solution if we want security (especially end-to-end encryption) built-in.

Protonmail has built a pretty cool solution, but it is not full open-sourced (and read their transparency page to see how much of a headache running an email service can be).

Even the security of services used by activists like Riseup, despite throwing in every trick in the book, ultimately relies on people's trust in the admins, and offloads any end-to-end encryption onto users (having to use browser plugins and PGP keys).

The ideal scenario might be to somehow negotiate a deal with Protonmail to run another instance of their server stack (or simply have accounts on their infrastructure, linked to our domain(s)), with public key federation (so that emails between social.coop and protonmail.ch would automatically be end-to-end encrypted).

I agree 100% with Mayel. Email is one of the trickiest, most demanding, and most unmerciful services to run, on top of that it's also the least profitable as corporations have created an expectation of gratis email (which they subsidise through their surveillance business model), and a kind of service that offers zero opportunity for differentiation (it either works and delivers emails properly, or it doesn't).

From every point of view except for the benefit of branding, email is a problem that is best outsourced. There's a cost to operating email services for hundreds of users, but I'm sure it's possible to find an ethical ISP keen on providing that service at a discounted rate.

Another example to illustrate the issue with email: scramble was a cool federated FLOSS project a while back, which shut down this year with the following message:

I apologize to the (apparently very few) people who may be inconvenienced by this :)

Scramble started back in late 2013 after the Snowden stories. We were shocked to learn how intrusive surveillance had gotten, and wanted to do something about it.

I'm happy to report that 3½ years later, end-to-end encryption is mainstream. The cool people at Signal and WhatsApp delivered strong crypto to over a billion people. For email, ProtonMail started with a very similar mission to ours and delivered a solid service. Check them out!

Another option may be Mailpile which is a modern webmail with built in PGP that can connect to any IMAP server.

I like this idea. I don't have a lot of knowledge about the FLOSS world lately, I'd welcome the opportunity to try out new apps & services.

FYI there's a interesting conversation about collaborative doc editors happening here: https://social.coop/web/statuses/1948774

Including this from @horatiotrobinson:

Jetpad is a better looking and less powerful clone of Etherpad.
Sharelatex and Hackmd are more powerful but also more specialised, less general-purpose.
Sharelatex is LaTeX document oriented. Hackmd is code-oriented

All 4 make their source code available, except Sharelatex shares only a basic version, a more powerful server is available commercially.

All 4 are nodejs-based, but Etherpad-Lite comes with an API that allows for Ruby integration

Again, can I ask that we focus on user needs? The language we're using here is pretty exclusionary for less technical members of social.coop. We're all here because we're interested in co-operativism, not discussing developer-focused technologies. There's plenty of places to discuss the pros and cons of various stacks and languages... ;)

Languages are important and non-exclusionary when it comes to analysing the costs. Costs are facts of life that programmers can't avoid. I'm doing my best to explain that costs exist and you can't make good decisions ignoring costs. That's not exclusionary, that's "inclusionary", in any case.

I'm aware that there are plenty of other places. Thanks for the suggestion.

Newbie here. Excellent idea with lots of potential!
I've been working with a few friends in the IndieWeb community to come up with http://indietech.rocks/ -- a "list of products that doesn't screw us" and which should have large overlap with what would be acceptable here.
Also, I'm the primary developer of UBOS (http://ubos.net/ ) a Linux distro specifically created for self-hosting web apps. It would be really easy to host and in particular maintain installations of apps such as Nextcloud if anybody here has any interest. Happy to help out.

Hi all! This discussion is shaping up nicely, and for that I thank you all. Before we get lost in technical details, though, how about we run a dot vote so all the members can prioiritize what's important for them? Does it make sense to you?

Yes, it's exciting to see all this shared enthusiasm about the possible solutions and how they could be tied together into the social.coop ecosystem! :) And I apologise to @dougbelshaw and any other member who felt excluded from this conversation. I'll try to write down my thoughts in layman’s terms:

We're in a pretty unique position here in that we already have a community of users who I think have gathered based on shared values (e.g. “I want my social media to be more decentralised/co-operative/user-centric/non-oligarchic/democratic/free-software-based/etc”), rather than shared needs (e.g. “I need a social media app”).

The way I see it, we're in a very different position from a startup founder (“oh! here's a [semi-]new idea, let's see if we can persuade people they need it”) or a free/libre software (FLOSS) developer (“oh! what a cool technical challenge!”). None of the services we'll be offering are unique (the needed functionality can already be found elsewhere), but what is unique is the values that will underpin them, which besides the co-operative way in which we will operate them, I think also includes how good a UX they offer, the values and dedication of their developers, if/how they can federate, how they're licensed, what technologies they're built with, and their hackability (to what extent and with how much effort we'll be able to customise/adapt them to our needs).

We have the chance here to bridge the gap between FLOSS developers and users, who often simply need an accessible and convenient way to, for example, share their availability and book appointments without Google mining their data, and without their correspondent being required to also use the same service provider.

Anyway, I was hoping to get some discussion going around points 2 (consensus on the criteria, which I hope the above will help trigger) and 3 (financial sustainability) before moving ahead with point 4 (choosing what services to start with). But if you prefer, like @michelekipiel suggested, I can start an open poll (so everyone can add options) for members to indicate what types of services they'd most want to see on social.coop (eg. Shared calendar app, Secure group chat) as a first step (leaving the choice of what software/solutions to try first for each type of service for later).

Has anyone tried Patchwork / SSB? It might be cool to explore hosting a social.coop SSB pub https://www.scuttlebutt.nz/faq/basics/pub.html

I've tried it. It's a bit rough. But yeah, it's very much aligned with what we're doing. I'm just nervous about competing with Mastodon, which itself doesn't feel like a critical mass yet.

In the Platform Coop Discussion list someone brought up a topic of creating a Platform Coop as an alternative Medium Platform Capitalism around their Subscription.

https://lists.riseup.net/www/arc/platformcoop-discuss/2017-10/msg00014.html

In the OP of this post there is a mention of going the blogging (ghost/wp) route over there and it was also suggested here. I think a good route would be to leverage libre licenses for content in a federated way and a fund to reward and attract both readers and writters?

Anyways, this post is mainly to connect the efforts of Social.Coop and Platform.Coop Mailing List.

As for the poll, I will second @dougbelshaw's point that we should focus on what we want rather than through which software it is provided and agree on @samtoland proposal to open a poll with the ability to add options for at least 2-3 weeks or leave it open as much as possible as an ongoing poll not as a binding result but as a guide of members' desires to be taken into account with both financial and technological feasibility.

Refreshing this thread. Perhaps it makes the most sense to start with a federated login system before adding anything else? Then anything else we add can make use of that? What if I were to make a proposal for this strategy?

From a strictly technical point of view, at first sight, it would appear a lot harder to start touching various systems that need to be maintained and upgraded in parallel. So there's both an initial cost, and a recurring cost associated in that. There's also a learning process involved in understanding (really intimately grokking) how each system does its authentication and security and then writing or reusing existing software to do the actual work of integrating a single login system for every single one of the applications involved. The more applications, the cost increases, linearly or worse. On the surface, it does not look like a good place to start. Part of the reason I've been suggesting that integration around one single application where the members already spend most of the time because that would be less costly, less complex from a security PoV, could possibly take less time to implement, and ultimately makes more sense from a UX PoV to have less context switching and less variety of UI semantics.

Which federated login system did you have in mind? #canofworms
IndieAuth is pretty nice: https://indieauth.com/

I haven't tried or tested them enough to know.

It might also be good to collaborate with the Framasoft community, since they offer a portfolio of FLOSS services like we are discussing here:

https://framasoft.org/

@brylie It's always good to cooperate with other cooperatives and it's one of the fundamental seven principles, and as such, if Framasoft are a co-op, that's going to be absolutely great.
However, we have been able to agree on very little here at this point, and internal education is lagging behind a lot, which makes random proposals difficult to conform a coherent vision.

I would say that it should be much higher priority to form a coherent and consistent vision internally, and a community where a majority of the co-op's members are educated about the issues at stake, well-informed, and on the same page before engaging in debate over these things with other organisations of any sort. We all are in touch with many other co-ops and organisations, and many of us know various types of software, I think it would be a good idea to capture this wealth of knowledge so that we can make smarter decisions together. Learning from others is always good, but maybe we should decide first what we want to learn and integrate according to our own aims, goals, and ethos following some sort of orderly process.

Not saying it's your case, @brylie (By the way, pleased to meet you!) but I still get the feeling that too many of us are too focused on the tooling without having had a discussion about a vision to hold this thing together, and then discuss the tooling that better suits that vision.

I still get the feeling that too many of us are too focused on the tooling without having had a discussion about a vision to hold this thing together, and then discuss the tooling that better suits that vision.

+1,000,000

Agreeing on what is needed is the hard work here, not messing around with the tech ;)

I'm confident that this is will be a great community that will do everything necessary to improve and develop itself beyond our wildest dreams. Everybody can get a little bit busy and juggling many different priorities, especially during this season, I totally understand that.

I'm also sure that once everybody gets excited about the things we're actually getting done and actually getting results, bikeshedding, pointless uninformed debate, and other generic excuses for lack of genuine involvement will feel like something of a distant past.

Educators, communicators, and media people will eventually play a crucial role in spreading best practices and effective ways of doing things, so I'm really confident that dysfunction will cease to be seen as a necessary element of cooperative work.

To infinity and beyond! ;)

As a UX designer, I couldn't agree more with you on this one. Actual needs (user requirements, in UX parlance) are the first thing we need to collect. Everything else comes after that.

How do we envision the membership evolving? It seems to me there are a lot of highly technical folks here because things like gitlab replacements and SSO infrastructure came up. Those probably won't be the vast majority if social.coop got quite big, though, right? I'm gonna go out on the limb and suggest, admittedly knowing basically zero of the history before I joined last week, that if social.coop got big, the tech types would probably be the core/"seed" users that sustain and grow it in the initial phases, and then we're likely to get a ton of people who aren't programmers.

My point is, we should probably consider the desired trajectory of the coop's userbase evolution here (as well as realistic constraints on the same). Obviously we techies need/want some stuff to keep us interested at the start, but it's gotta be balanced with the needs we anticipate from our expanding userbase.

Anyway, thinking about it in that light and as a technically oriented user myself, I think that a Nextcloud-type installation should be real high on the priority list. I know activisty types who want Nextcloud now but don't have the resources to get their own running and don't trust the commercial hosts.

Aside from that, I'd love to see services to serve media, so, a simple platform for serving images, video, and audio. The simpler the better IMO, as I envision the main use case being embedding. That will bring up a discussion of storage and bandwidth, I'm sure, but if there's one decentralized but reliable service I keep wishing for year after year, it's a way to serve images/videos/audio that isn't imgur/youtube/soundcloud. I think the best candidate software should have a limited set of core features (think imgur, not flickr) because not having 300 social networking features bolted on certainly reduces the amount of time spent worrying about the services in an administrative capacity - less software complexity and fewer use cases for users to cause/find/experience problems.

1. In order to assess the simplicity and associated costs of solutions, the feature sets and costs have to be discussed. Those aren't techie things about programming. I have already given a detailed explanation about this above. It's a topic that keeps coming back, it can be answered reading the posts above.
2. Everybody has a list of favourite things. It's like that episode of Orange is the New Black where some inmates were activist types who wanted better living conditions for everybody, and a group of them were debating what type of peanut butter they liked better to introduce it in the list of demands. When the odious techie types that everybody reviles are discussing things like file formats and the gitbook or gollum tools (not gitlab, that's a different application) they're doing that because they're taking the responsibility of doing something that's in their experience and their capacity to anticipate problems and preserve data in for everybody in the future. They're not discussing that because they want to exclude or annoy non-techie people. And so far they're doing an excellent job, pro bono, with very little expectation of having any compensation for the foreseeable time. It's not a Bing Bang Theory character flaw that mainstream media have trained people to hate. There's no need to introduce divisive labeling all the time, or elucubrate about second motives that the much reviled techies might possibly have. Trust me, the quality of the job these guys have been doing is world class, and they're doing it out of sheer passion alone. These guys aren't Zuckerberg, they aren't billionaires, they're not making a single cent, and I'm not sure where this deep distrust comes from. Maybe ask why these discussions are necessary first.
   
3. We need to capture knowldege about the things people need. Not having a collaborative content management system of some sort (gitbook, wikis, or something else) is a show stopper because it prevents everybody from contributing their input in the form of actual useful information, instead of the type of cathartic exercise that free form discussion can often take. Mayel installed a wiki tool (at: https://wiki.social.coop) yesterday, so this is a good first step. A content management system is not just any tool, but the kind of tool that will help us to bring about more cohesion and common purpose to build the internal knowledge that functional communities need in order to develop themselves. The tools are secondary to the vision of any community, yet we keep adding lists of tools instead of presenting typical use cases that social.coop should contemplate. "Just give us X, Y, and Z tools" or "I saw that my friend X had tool Y" isn't useful input. Examples of useful input: "We need to keep photo galleries of the coop conferences we attend". "I would like to have pre-defined social.coop marketing templates to send out email to prospective coop members". "I would like to have the ability to create newsletters for my network of gardener coops".

Very well put. Point 3 is of the utmost importance to me.

I suggest to begin with a simple poll (5/6 multiple choice questions, one comment field at the end and possibly a Likert scale) to identify where we stand as of now. I'd suggest we assess the general situation with questions like "how much time do you spend on mastodon", "what is your relationship with the cooperative?", "is social.coop your main instance" or "do you consider social.coop to be a trusted "brand"?"; then we could ask people to pick the service(s) they'd like to be provided with by social.coop from a list. Finally, we could ask for a generic comment on what social.coop is to them, to better understand what's our "reputation" with our users.

The replies will (hopefully) tell us where we need to focus our attention (eg. there's no point in developing new services if our own users don't trust us).

Once we're done with the poll, we can kick off the technical debate on what to host and where, based on the actual needs of our user base.

I like the idea, if it's conducive to capturing useful user stories (in the sense of the Agile method). It's not helpful if all we get is a wishlist.

1. WISHLISTS VS USER STORIES

Wishlists are bad because they take neither value nor cost into consideration.

Wishlists are something you send to Santa Claus.

User Stories are helpful to understand the value you deliver to users, and the cost of servicing that demand.
https://en.wikipedia.org/wiki/User_story

User stories in the new wiki, captured and normalised in a way that can lead to organised development would be helpful. Take for example:

https://en.wikipedia.org/wiki/User_story#Common_templates

1. MIS-ALIGNED EXPECTATIONS

There may be an existing expectation that technology services organisations deliver things in ways similar to the way Google or Microsoft do it. Helping users to learn a different perspective is important too, because riding your own car implies that you have to be conscious about the cost of putting gas in the tank, and keeping the car well-maintained. I may have been wrong to assume that everybody was on the same page regarding this.

You never have to worry about Gmail, or how much it costs (breaking news: it's not $0) and you can curse Google all you want when it doesn't work. What social.coop is trying to do is very different, and an entirely different set of expectations should be communicated more clearly. The Silicon Valley industry has trained people to stay infantilised because that's how their business model gets to rip them off. The way I understand social.coop wants to be seems diametrically opposite to the Silicon Valley way, and that's precisely the core of its value proposition. It's a terrible misunderstanding if people expect to receive the exact opposite of what you're trying to deliver.

The communication problems and misunderstandings are not about algorithms, programming languages, or the dastardly evil techies who don't read letters to Santa and don't give candy to the users. Users with mis-aligned expectations might as well feel they're only getting a sack of coal.

1. MAKING PROGRESS

But then, again, you can't communicate these things without a public communication channel (like a blog), and without some minimal knowledge management (such as gitbook or wiki). So breaking the vicious cycle with the show stoppers was the first step, it's already happening, and it's work in progress. So far so good.

The next step is to capture knowledge (gathering user stories seems to be important right now), communicate, and get expectations aligned.

I took the liberty to fomalize the survey questions in a first draft, which will help us identify the following:

• what is the overall trust level
• whether there is a connection between engagement (both with the instance and with the cooperative) and specific patterns of requests
• what are the most desired services
• how much cooperative ownership and decentralization are valued

The attachment is an ods spreadsheet, so it should work for everyone. If not, let me know.

I agree on all these except "what are the most desired services". Again, I insist, User Stories, not Wishlists.

Example:

Wishlist: I want to edit Excel files on social.coop.
= BAD (focus on mechanics, and the how)

User Story: As a social.copp user I would like to be able to share with our fellow coop members an updated price listing of the products my clothing coop has to offer.
= GOOD (focus on value, the what, not mechanics)

Interaction mechanics are less relevant in the particular situation we are now.
We need to understand the value that users need to be delivered to them.

Interaction mechanics shift attention away from the what delivers value, focusing on the how, and specifics of the tooling without discussing matters of value and cost.

The what, not the how, is what the current moment demands.
There is no question that interaction analysis is super important and needs to be done too, but interaction analysis is one specific aspect of many aspects of a larger thing.

(like, say, you can't use UX alone to learn how much it will cost to provide email services, or project management services)

These aren't mutually exclusive things, but the level of specificity and the way the problems are framed makes all the difference.

Also, if we can make things collaborative, transparent, and visible on the web, all the better. Sending spreadsheets around does not achieve that.

That's what the new Wiki is for.
https://wiki.social.coop

I should have explained the question better, my bad. It was never intended as a wishlist, but as a way to understand what our users find most useful. As such, it isn't an open ended question: the answers provided will be carefully curated based on the insight provided by the "tech branch".

I rephrased the question as: "Which of the following services play the biggest role in your digital life?", so users won't be left thinking "what would I like to have?" but rather "what are the things I use the most?". This way we'll have an insight into what's relevant for our potential users without the risk of them going full wishlist on us.

Last but not least: I will definitely post the questions and the results on the wiki, but after the survey is done. If we "spoil" the questions, the answers are less likely to be natural, thus less useful. For the time being, I moved the file to a shared folder:
https://www.dropbox.com/s/iypd8ivcfjbw4wn/survey_1.ods?dl=0

Survey nitpick: How much do you agree with the followng statement: "Cooperative ownership and decentralization are core values in my digital life" -- that's two statements, really. Decentralization is important to me. I've barely touched coops.