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.

Good catch! I'll amend that and split the question in two, so we can rate the engagment independently.

To clarify I looked at this survey draft you uploaded on Loomio - rather than the dropbox one linked in the survey check. Hopefully they are the same and my comments make sense.

I've got the uMatrix add-on on my browser and, possibly somewhat over enthusiastically, disabled scripts to all but sites I trust since the recent Spectre / Meltdown exploits were disclosed. Dropbox appears to need scripts enabled to work and I've never much liked/trusted them - so I downloaded this version instead.

Further in this vein and as a bit of an aside - I've always tried to avoid using Google docs - but often found myself working with people that love them. I try to use etherpad and ethercalc (spreadsheet) wherever possible instead.

http://board.net/ offer a nice pad service.

There is pad and calc available from the awesome Disroot crew at https://disroot.org/en/services/pads although the 'branding' there may not be to everyones taste.

New services for the group, or for the individuals in the group?

Example: a wiki. If we provided a wiki for the group, then it would be one wiki that everybody got to edit. So there would be one entry for, say, "Good cookie recipies" and it would contain the union of all recipies that group members thought are good.

But if it was for the individuals in the group, then there would be one wiki per individual, and up to N "Good cookie recipies" pages on N wikis. Each of those would only contain those recipies that the owning individual thought were good.

Obviously the way such new services would be used would be completely different in those two cases. Which one did you guys have in mind? (Similar situations for many other of the candidate services that were listed above)

Hi Johannes, pleased to meet you :-) You make an interesting point.
I think the discussion so far can be resumed, more or less chronologically as:

1. "Let's install some new things on social.coop"
2. "Wait a minute, we haven't decided that we want things"
3. "That's true, let's discuss what we want."
4. < Banter Banter Banter Banter >
5. "Bad techies are bad, they don't pay attention to us and they want to build things"
6. "Okay, we're not getting useful information. We need to figure out what people need somehow
7. < Wiki installed to capture knowledge and user input > https://wiki.social.coop
8. < social.coop blog in the process of being set up right now >
9. < Mastodon bots and scripts in the process of being created >
10. Hi Johannes, pleased to meet you :-)

In my view, we should think of the current wiki as a shared collaborative wiki space for the social.coop people to create community, capture knowledge, and document things.
If in the process of capturing user input we find out that many users need wikis, those will be separate wikis for the people who want to have them.
So the current wiki, blog, mastodon bots, in development aren't services for individual social.coop users, but meant as supporting tools that will enable us to set up the scaffolding necessary to later, in turn, build the things that people need.

Hope I'm not being too confusing!

@h Good description :-)
I think there's a larger question about how social.coop understands itself. Example: the existing Mastodon instance: there is one instance shared by everybody, ergo, everybody has a social.coop identifier. Which is fine. But there is an alternate way it could be done, which is that everybody gets -- if they want to -- bring their own domain name, and social.coop is just in the business of hosting separate Mastodon instances on behalf of its members, who, if they ever wanted to, could move their domain name and Mastodon instance somewhere else. (I'm ignoring the possible complications of N instances on the same host, I don't think Mastodon is made for that) The use cases and value propositions for those two alternatives, obviously, differ.

Described that way, it sounds like the case of hosting services an ISP would provide, and there's a few of those already. However hosting social media services, as opposed to traditional, basic web hosting is a little bit different. I haven't discussed these things with others, but it's not entirely unlikely that both ways could co-exist one day.

I think the vision that @matthewcropp, @mayel, @michelekipiel and others have been working on so far is predicated on the idea of taking social media back for ourselves, run by ourselves. One part of that is there must be an infrastructure in place to support social media. The other part is perhaps, we've only been learning what this new type of federated social media actually means in the last 8 months. As this learning process expands, it's well possible that it may grow to help coops develop their own brand identities in the cases that require it.

This might mean that there may be a new niche opening somewhere in between social media and traditional ISP hosting. That may potentially exist, but it's certainly not something obvious or definite at the present time.

I'm sure that this discussion will keep emerging from time to time, and as enough people become more aware of an emerging pattern, we will surely have to evaluate whether becoming a SMSP (Social Media Services Provider, I've just made that up) is something that social.coop can do and/or wants to do.

Great to see the wiki up, @h! Is there any way that we can start with the open-auth with this, and create a common login system between the wiki and mastodon?

Oh never mind, I see OAuth is already there! Just not working quite yet. But awesome! I love it!

The credit for the wiki work goes to @mayel , I've only been pestering people to get things moving :-)

Can we actually log in to and use the wiki yet, or not?

You can create a user and use the wiki right now.
The wiki user you create will not be associated to your Loomio or Mastodon accounts.

That's inconvenient, but it's something that's going to take a while more and more work to be fixed.

In the meantime it's advisable that the usernames we create on the different services be the same, and associated with the same email address.

We can't enforce those rules, and the systems will still be disconnected, but that will make it easier to weave things together when the OAuth system is ready.

Hi @j12t and welcome :) Since the beginning of our adventure, social.coop was very much intended as an experiment in cooperative social media ownership as a form of self defence against the invasive, extractive nature of corporate social media. Theoretically, there's nothing standing in the way of social.coop becoming a hosting/ISP hybrid, but as of today such an evolution is way beyond our scope, capabilities and necessities. That's why, as @horatiotrobinson correctly pointed out, we are looking more into expanding the range of social services provided to our members, as that's much more in line with our initial mission.

The indieweb have a concept called POSSE (Publish (on your) Own Site, Syndicate Elsewhere). https://indieweb.org/POSSE.
This is intended to put the user at the center, and spread tentacles out to all the other apps being used.

Would this be the kind of service we should be considering? It does seem to be individual focused.

Alan: it's actually a principle, and a set of protocols around that. So it's not a service per se (although there's a service called brid.gy that makes it easier). But to your point, I very much believe it would be very consistent with the principles in this community.

Disclaimer: I consider myself part of the IndieWeb community, and in fact just published a Tutorial how to setup POSSE and a few related things using Wordpress on Amazon EC2: https://indieweb.org/Tutorial:_Set_up_an_IndieWebSite_using_WordPress_on_the_Amazon_cloud

Since I received no further feedback regarding the survey questions, I'd say let's go to the next phase: @horatiotrobinson @mayel @williammurphy could you please create a shortlist of services based on feasibility, cost and maintenance effort? As I explained a few posts earlier, this list will be put in the survey to help us identify which of them is more commonly used by our users. Thanks!

Sorry, I must have misunderstood. I thought the spreadsheet was a draft and you were going to follow up with a web form or Loomio survey. I'm not sure what's the next step?

Unfortunately Loomio doesn't have a proper survey tool (not one with Likert scales, at least) so we'll need to either go through an external service (eg. Surveymonkey) or ask @mayel to help us with this using his survey tool.

But before doing that, I would need the tech branch to shortlist the services that we can afford offering on a cost and maintenance level, so we don't overstretch ourselves (for instance, when we agreed email was too "expensive" to maintain ourselves etc..). If you all could come up with such a shortlist, I would then use it in the question about which services our members use the most.

Thanks!

@mayel @williammurphy @horatiotrobinson any chance you had the time to evaluate the services and come up with a shortlist? :) Thanks!

Can you clarify what you mean by services? Things went sideways the last time I suggested we discuss this topic, so I'm hesitant now... Looks like most people want to start by talking about what type of services they need (or which ones they use that social.coop could replace) rather than any specific solutions?

Sure thing. As you may know, I developed a survey to collect feedback from our users/members regarding their "digital habits" and how much trust they put into social.coop, to further our understanding of the potential "user base" prior to investing in developing additional services.

One of the questions asks people to pick which services play the biggest role in their digital lives out of a list, so to prevent them simply sending us a "wishlist". In order to collect relevant data, we need to provide them with a list of options that's sensible from a cost, effort and maintenance point of view (eg. we already stated that hosting an email server would be too costly, so email won't be listed in the question).

If you guys could come up with such a curated shortlist I could then finalize the survey and have it served to our users/members ASAP.

Thanks!

Ok, I started drafting a list, trying to focus on user needs or things they may already use, and separated into social/collaborative ones vs. more individual-oriented (its on the wiki to make it more easily collaborative): https://wiki.social.coop/New_services

I believe we should focus on the social/collaborative section in this phase, what's your take @mayel ?

I agree, but if this is just a survey, why not include everything and assess what members' take is.

The wording of the questions is important

I simplified the list a little, grouping similar software (eg. the three types of proposed forums), so it's a little less overwhelming. I'll updated the shared spreadsheet later today and post it again for review.

We added an article about WeCollective to the Wiki with @jamesweir , would love to hear your feedback. On the bottom of the article there's 6 specific questions. There's separate thread about it on Loomio here.

I also made a private Youtube video specifically for the Social Coop folks demonstrating one cool thing we could do together in WeCollective.

I love this scheme and am really excited to move forward with it! What next?

Glad to see interest around this :) The planned next step is a survey (90% ready) that will help us assess both the level of trust of our members towards social.coop as a service provider AND determine (in a smart, non-wishlist way) which services are the most relevant to our members. The data gathered via this survey will inform our further decisions.

Hello everyone, sorry for the delay! Here's the finalized survey: https://www.dropbox.com/s/iypd8ivcfjbw4wn/survey_1.ods?dl=0

Feel free to review it and let me know if there's anything missing and/or hard to understand.

Thank you all!

@michelekipiel can you embed the link to the survey in the check poll?

Done!

I have been feeling a bit lost on social.coop lately. We have a lot of FLOSS devs and activists among our members with the result that much of the feed is acronyms esoteric discussion of coding issues. Most of it is well beyond my technical understanding. At the same time, I see very little about co-ops, enterprise, or economics. It's frustrating. Where are the cooperators?
This discussion of services and tools is likewise frustrating, because I don't feel like we've got the core community happening yet.

Well, unfortunately, a lot of the co-op people I know who have tried to come on board have gotten lost in the technical problems with the on-boarding stuff. Hopefully we can come to some resolution on that soon. I know the tech team is working on that.

A great point, but I believe the abundance of tech-talk is a consequence of the enthusiasm for the new services, in a way. I agree with you this specific thread is not the best place to address tech issues though. Maybe we should consider creating a dedicated thread in the tech working group and move part of the discussion there...

If it helps, I'll talk there about what I'm doing with/for co-ops. It's independent of the technical stuff (for now).

I'd love to read about that. Please, feel free to open a new thread to cover your current activities!

Idea (which I will also post to the instance):

Social.coop becomes a Faircoin node, and we start using Faircoin as a membership payment option? I wonder if we could automate membership to a certain extent by tying it to an individualized member key that is activated for a certain amount of time each time "dues" are paid, with an online wallet allowing people to "pre-pay" by depositing multiple months worth of currency? Social.coop could then double as a faircoin wallet with the monthly dues/fee also covering the Mastodon instance and other services?

Yes I fully support federating with Faircoop. In fact it could be very productive as it seems social.coop is very service oriented and I think a sustainable business model could be in hosting floss and collaborative tools at a member rate for cooperatives and commons oriented projects particularly revenue generating ones and low to no cost services for community, voluntary associations.

I also love the idea of becoming a FairCoop node, but I'm not sure that it's a good move right now to try to build our member system around faircoin. To be as accessible as possible, I'd keep that in fiat for now. (Even though, given FAIR's system, it is quasi-fiat, which I don't think is a bad thing!)

Great idea. We would surely support that at FairCoop!

I agree with @ntnsndr , let's not marginalize ourselves. We can accept both fiat currencies and faircoin at the same time :)