Just for the record, we (discourse.org) would be happy to host the IPFS community for free.

I'm a big fan of the IPFS project and have been casually following it for some time. Today I happened upon the "Community" section of your docs and I found it quite daunting. I wanted to get an idea of the latest going-ons in the community, but in order to do that I had to:

• Browse individual GitHub repositories
• Browse a separate Google Group
• Dig up and browse discussion repos that haven't been listed, like POST.

I think these discussions would be a lot easier for newcomers to catch up on and get into if they took place in a purpose-built platform such as Discourse. @fazo96's discussion board project looks really cool, but as I'm sure he realised, making a scalable and user friendly forum platform takes a lot of time and effort. A decentralised platform is definitely more in line with the IPFS ethos, but it's not like you have to check all these boxes right out of the gate. Discourse offers exhaustive data exports, so you could take your data and leave when good and ready.

it is very time consuming and hard for core devs to keep up with notifications as it is, adding more channels will worsen this.

Wasn't the idea originally suggested here to converge on one platform exactly so that there would be fewer notification sources? If you used Discourse, none of your "discussion repos" would have to exist, nor would your Google Group. We have migration paths for both:

• Google Groups to Discourse
• GitHub Issues to Discourse

They're not perfect, because the data accessible to us is limited, but the most important thing is just getting the content moved over so the new forum doesn't start out as a ghost town.

every discourse site i've participated in promotes "the act of posting messages" over "the act of communicating ideas", so in my experience the tends to devolve into very low SNR.

I'd love to know which communities you're referring to. Communities like Rust and Atom.io have been using Discourse very effectively, and even as a response to GitHub Issues getting too discussion oriented.

from community.

As seen from the logs, I would very much appreciate a forum for discussing IPFS and IPFS related things like IPNS and the technologies around the whole shebang. Also, closing down the number of places we discuss things would be good. There are a number of benefits, biggest ones being easy for newcomers to find information and getting into the community, and better search-ability (lacking another word for this...)

from community.

i chatted with @dignifiedquire about this a while back, and I expressed my strong resistance to discourse.org.

My reservations in general are:

• we already have many official comm channels:
  • github org with many, many repos, where most discussion happens
  • #ipfs IRC Channel on freenode
  • ipfs-users mailing list, which is very low traffic, as most people post here.
• some unofficial:
  • r/ipfs a wider community discussion forum
  • #ipfs on Twitter, + @IPFSbot
• it is very time consuming and hard for core devs to keep up with notifications as it is, adding more channels will worsen this.
• core devs want to be able to chime into discussions. keeping things in one place helps a lot with this.
• where protocols, code, and helping users are concerned, we want to keep high SNR discussions.

Now, my personal opinion on discourse itself:

• every discourse site i've participated in promotes "the act of posting messages" over "the act of communicating ideas", so in my experience the tends to devolve into very low SNR.
• to me, the UI/UX feels very hostile. i personally won't use it. feel free to have one, but i won't be there.
• discourse is yet-another centralized comm platform. i would like to have something distributed
• it's another damn silo!! -- i'm sick and tired of information silos that hold our data hostage! Our comm data belongs on the web itself, and this is what ipfs is for! i can't wait till we have something as good as github issues so we can ditch it for the web itself! /rant.

However...

However, I do recognize the value and need for general forums where people can discuss and propose anything. (something like a subreddit or a general forum). Free form discussion is very valuable to communities. So I do recognize the need for something like discourse.

My Proposal

There's people working on building towards forum solutions on ipfs itself:

• Several people are working on forums and other chat things over IPFS:
  • @nginnever on https://github.com/nginnever/swarmchan
  • @fazo96 on https://github.com/fazo96/ipfs-boards
  • @haadcode on https://github.com/haadcode/anonymous-networks
• Some (I and others) have been working on defining a general data-structure on IPFS itself for "communications in general", something to represent {blogs, tweets, articles, IM, forums, etc ... } (We call it "POST").
  • this is to separate the comm data from the comm UI, so that we can have many viewers over the same data! no more silos! more on this soon
• Some have been working on distributed identity independent of a central authority and DNS.

I say that we channel the energy and desire for a forum into building our own board on top of ipfs itself.

We're not far, and this will make us achieve three very important goals:

• We dogfood and improve ipfs -- it will drive development of features, apis, tools, bugfixes, etc.
• We develop much-needed libs to easily make webapps on ipfs
• We make distributed web-based comm tools that help put users in control, and might become a new standard for open source (and other) projects

Obviously achieving parity with github issues or discourse is very, very hard. but i'm willing to bet that if we have something very simple that works, totally open source, distributed, and hackable, it will promote an explosion of communication UIs on top of a core communication datastructure.

from community.

@davidar I like this idea (in practice), of having a list of questions on ipfs/ipfs/README.md

FAQs

• What is the goal of IPFS
• Is it Open Source?
• How do I help?
• How does it compare to...
• Who designed it?
• What is the relation to Filecoin?
• Why the name IPFS?

I just think a solution like this (which has half data on ipfs/faqs and half on ipfs/ipfs) is going to put us in a situation where it's waiting to become inconsistent

from community.

We will finalize the decision about Discourse on Friday 17 March 2017.

I've made a decision document that we can use to finally pull the trigger on this decision. See #246

If you have modifications to the proposal, modifications to the background information or if you want to block this proposal and argue for an alternative, please speak up before Friday.

from community.

Don't forget about https://www.discourse.org/github for the moving process! More about it here:

https://meta.discourse.org/t/introducing-github-issues-to-discourse/46671?u=erlend_sh

from community.

What would be really cool is a web forum built on IPFS.

from community.

@amstocker yes that would be a great project. But it will be along way to having a forum on the level of discourse and until we have I feel it's important to use existing tools that are working very well for other communities.

from community.

Well looks like I should have used the search first. feels stupid now

Ref #15

That being said I still think that there is room for improvement, from my side it doesn't have to be discourse but a proper forum software could help a lot especially for newcomers to the community.

from community.

@dignifiedquire I definitely agree that we need an established web forum, I was just throwing the IPFS forum idea out there :) . Right now in order to keep up I just go into the IRC logs and CTRL+F my username and several other keywords of interest (e.g. python, etc.), then I also browse the monday sprint logs and todo lists and watch a handful of ipfs github repos. Maybe we should make a subreddit like /r/ipfs-dev or something like that? The current one (https://www.reddit.com/r/ipfs) seems to have a decent amount of activity.

from community.

just to point out, we have https://github.com/ipfs/community and https://github.com/ipfs/support

If anyone wants to take a more active role in the community, we can make you a collaborator (mod) on either, giving you the ability to tag, edit and close posts. (And change readme stuff)

from community.

@amstocker I am building a Discussion Board platform on top of IPFS. I plan to open source it in the following days, I need to finish the prototype and the documentation. Maybe, when it works well enough (it needs some feature in go-ipfs 0.4 to be completed) it could be used for discussion. EDIT: here's the link to the repo

However I think a discourse server, a custom platform or any other solution that requires allocating time away from other more important matters is not a goold solution, even though the discussions are fragmented right now, they still work fine

from community.

It would be really, really rad if we could get a "github issues like" post system on top of ipfs. we're really there. it would also motivate us to fix a lot of things on our end. to make life easy we can run a hosted instance that delegates ipfs ops to our nodes until the js-ipfs node is ready.

from community.

@fazo96 have a link to a working example? what do you need from the gateway to make it work? is writable enough?

from community.

@jbenet there you go: http://ipfs.io/ipfs/Qmbf34Vdo3TtnFugSQQPzGfjjq6SBcgDfBB6P9kmSQs9Ay

It should work except when IPNS records expire and no one on the network has them. It should work better on 0.4, but there's no one with actual data for the platform so you can't test it yet. Next think I'll write is ability to publish stuff from the browser (which will only support go-ipfs 0.4 because I need that sweet files api) so that it gets a little more usable.

Everything I need to make it work is already in go-ipfs 0.4

Of course, when js-ipfs hits our browsers, you won't even need a local go-ipfs instance

Here's the repo if you want to take a look at how it works: https://github.com/fazo96/ipfs-boards

EDIT: my platform is like a discussion board, it has almost all the features you would need for replacing the github issues, so when it's done (or at least ready) it could be used :)

from community.

@dignifiedquire:

Well looks like I should have used the search first. feels stupid now

Don't feel stupid! We should have dealt with that issue. You're 100% on point and awesome for bringing this up.

@fazo96, that looks awesome.

However I think a discourse server, a custom platform or any other solution that requires allocating time away from other more important matters is not a goold solution, even though the discussions are fragmented right now, they still work fine

I agree with this. I think that ipfs/community and ipfs/support meet our needs at the moment, and that a lot of issues can be dealt with by better signposting. I've been going through and working on those (see PRs above), and will continue to think about how our community looks to a newcomer. But a forum would be great! I just don't want to add another standard lest we XKCD the whole shebang. (I didn't even know there was a subreddit for IPFS).

from community.

Relevant:

21:29 <•jbenet> M-davidar mek the original goal was to use the discussions to reach a concrete answer (update the first post on the issue) and then use a script to dump it into markdown and show it at https://ipfs.io/docs/faq
21:32 <•jbenet> M-davidar mek but open to other ideas to make it more discoverable. the thing though is that i do want to keep it as a github issues discussion because github issues is the best communications tool we have (allowing identity, hypermedia linking/embedding, subscribing, notifications, listing, tags, etc). ---- we all already have way too many comm
21:32 <•jbenet> channels and dont want to add more-- i'm drowning in notifications as it is, and i do want to be able to respond to FAQs very easily. (hence not moving to something like discourse, etc)

from community.

cc @mekarpeles @davidar as they're interested in this too.

from community.

+1 for common denominator message formats like "POST". I see this as the parallel to WebDAV. Over this, it could be very practical to support other formats like Calendar functionality (CalDAV), todo lists & issues,

We're not far, and this will make us achieve

Also a great way to isolate "practical" usability issues that the [developer] community will likely care about and face as they write apps (like @haadcode's which I thought was great).

discourse.org (rant)

It has some nice features (just as slack does), and they have the potential to be helpful (in their own regards) -- but the biggest feature of a communication service (as @jbenet suggests) is that all relevant data can't be navigated from within the same stream. Otherwise (what we have today) is like driving an automobile and having your speedometer on your phone and your fuel level sensor on a radio station. You can use some of these services in parallel, and context switch between others quickly, but if there's not continuity between your data sources, there's no filter mechanism or policy, no matter how creative, which can make up for this. It wouldn't be acceptable for a navy pilot to have dropped messages, and I think taking extreme edge cases like this is a good way to see how we really feel about such problems. And I don't believe pilots are the only folks with mission critical things to communicate.

from community.

@jbenet in terms of making the faq discoverable, I think organising it under a bunch of broad headings and making it prominent in ipfs.io (in the same way as support pages on other sites) would be good

👍 to forums on IPFS. I've mentioned the "POST" idea to the Matrix folks (cc @ara4n) who I think will have some valuable input on this. Note that whilst matrix is currently mostly being used for decentralised chat, they also have longer term plans for decentralised forums, etc. They're also very interested in bridging existing silos into the decentralised network, which reduces a lot of the friction of adoption.

from community.

@mekarpeles personally I would migrate concrete answers out of ipfs/faq and only leave the new/unresolved questions, but that might require some work

from community.

@davidar interesting, we could also experiment with having (on ipfs/ipfs) a list of links to issues, and making sure questions have corresponding issues. This way we don't need a FAQs doc at all and can manage answers w/ and w/o answers. Some FAQ items may seem more like threads than answers though...

from community.

Some (I and others) have been working on defining a general data-structure on IPFS itself for "communications in general", something to represent {blogs, tweets, articles, IM, forums, etc ... } (We call it "POST").

this is to separate the comm data from the comm UI, so that we can have many viewers over the same data! no more silos! more on this soon

@jbenet that is a great idea! I'm working on my discussion boards in the same way. I'm separating:

• the data structure (pretty much done)
• the API to access the data (half done)
• the actual user interface to interact with the data (about 25% there)

I also have plans to extend the data structure a lot. This will include things like real time chatting, git repo hosting, any kind of media support, tags, a search engine, reputation system... These are just plans. I'm now implementing the basics.

I can't wait to see what you've been working on in this context!

I think since we are pretty much doing the same thing, we should communicate more, maybe we can help each other solve different problems. Or maybe ditch mine and use yours (which is probably better) seeing that my app is built so that replacing a layer is as easy as it can be. There is no data structure logic in the app, it's abstracted away in a separate API

from community.

@fazo96 nice to meet you. @davidar and I are planning to have a brainstorming session about this tomorrow ~3p PST (it may be a bit late, your time but you're welcome to join us)

from community.

@mekarpeles nice to meet you too 👍 I'm very glad to be invited. These days I'm staying up late, so I think I will make it

from community.

Hello everyone I haven't met yet @fazo96 @mekarpeles @haadcode o/

Happy to help develop the IPFS communication web application. I've been working a great deal with smart contracts as a distributed data syncing system over IPNS. This actually gives nice properties such as identity and post permissions inherited from bitcoin that work atm. However it costs money to post which sucks so I have been and would love to work more with others on an IPNS solution.

Some (I and others) have been working on defining a general data-structure on IPFS itself for "communications in general", something to represent {blogs, tweets, articles, IM, forums, etc ... } (We call it "POST").

I've been hearing about this, great! Can't wait to learn more about what you guys are cooking up. I'll be in the discussions on IRC and hangouts today.

from community.

@nginnever Hello! Nice to meet you 👍

I've been working on exactly that: a communication web application (fully static: no backend needed) that works over IPFS and IPNS only. The prototype is coming along nice: I managed to find solutions to most common problems with this kind of projects but not everything is perfect yet. The biggest problem is that it will be very hard to scale: the client needs to aggregate everything alone because there is no blockchain and all data is scattered across different sources. This can be a big problem when the numbers go up and there's a lot of data

I'd be really really glad if someone else other than me had the time to look over my protocol and ideas at the github repo

Also soon after IPFS 0.4 is ready I plan to get the prototype to the point where it can be used seriously 👍

from community.

@fazo96 Actually started reviewing your repo this morning. Really good ideas you have going. And you're right, getting consensus at scale could be difficult and why I have been using blockchains even though they are expensive and currently it takes ~12 second block times to sync the data (Which would lower with Ether POS but still hard to get block times down to sub-second confirmations). I'll give it some more thought and let's share some ideas on IRC or hangout today!

from community.

cc @harlantwood

from community.

👍 to getting something working on IPFS

from community.

Fantastic discussion today:

• ipfs/team-mgmt#56 (comment)
• https://github.com/ipfs/POST

from community.

Discourse is an excellent platform for what is currently missing for IPFS community, a living example is Caddy Community forum, that while introducing more noise yields a lot more fruits that would not as easily grow anywhere else.

Personally I find Discourse easy to navigate, handle, manage, and inline code from github makes managing help a better experience.

As someone that is trying to keep outlook consistently, I thought I will chime in.

Reactions

victorbjelkholm:
maybe we should write a distributed forum on ipfs that collects all the question from different github repos

I would implement a means of search over all github issues on all ipfs (and optionaly related) repos. Finding anything in general from a user / third-party dev perspective is very daunting.

richardlitt:
Well, we could shut down the google groups, FAQ, and Support.

I would think about closing/migrating google groups to Discourse

RichardLitt:
will continue to think about how our community looks to a newcomer

Very hard to navigate, hard to find relevant answers, documentation and materials,
for irc familiar people, it looks welcoming, for some irc is a limiting factor (make Matrix more visible? - like http://rauchg.com/slackin/)

<•jbenet> M-davidar mek but open to other ideas to make it more discoverable. the thing though is that i do want to keep it as a github issues discussion because github issues is the best communications tool we have (allowing identity, hypermedia linking/embedding, subscribing, notifications, listing, tags, etc). ---- we all already have way too many comm

Github is an excellent place for ipfs developer and contributor issues/discussions.
Discourse could be leveraged for the user base, lowering SNR of github and other channels, and having a platform where users are not bound by fear of introducing more noise and therefore hesitating to ask. (As per previous note, this would probably replace Google Groups)

from community.

We discussed this on today's all-hands call. There is a lot of interest in doing a trial run with discourse to see if it's a good fit for us. See #190 to participate in that experiment and/or to follow along.

from community.

Notes from discussion about discourse during today's sprint call:

Discourse - To kill or not to kill

If we do this, github will still handle feature requests, bug reports, design discussions, or any other discusions that are aimed at discrete tasks or improvements. By contrast, Discourse wil be our platform for Q&A and also the primary platform for asynchronous open-ended community discussions, or any other discussions that are not aimed at a discrete task.

David: need to list out the actions to get discourse to work:

• notify the community - We have never actively announced the communication channel
• Compile all answers so they are easy to get to, saves time in the future.
  Freidel: Docs page need a big button that points to discourse.
• If there are missing docs we need to have an obvious place for them to go.
• FAQ, no matter what, go through and pick out the ideas we like and add them to the readme
• there are many more actions/steps outlined in github issues must look them up

Discussion:

• It's good at searching answers
• Bring Stack Exchange into the conversation, Community can get points/gratification.
• Feel that if we invest the time telling the community that issues on github, 80%
• Discourse may be better than spending more effort on github.
• FAQ, questions can't be mixed, other communities host FAQ on there website
  Matt: there are a number of ways to configure notifications
• discourse allows questions to be asked and decisions to be made
• Which do we want, hesitate to setup both Stack Overflow.
• We are using Github outside its normal use - The system is not designed for finding answers to questions.
• We need to keep the appropriate discussions in github, but there are other types of discussions that don't work so well on Github.
• Things that are getting missed currently will have a place to land.
• A place where contributors have an open channel.
  Lars: - Agree that Stack Overflow is good
• FAQ and Support repo's overlap with this issue.
• Stack Exchange is good for questions.
• FAQ repo, content, 30% of the questions might get filtered , will not have control of how things stay around.
• People hesitate to answer questions in a Github repository that they're not a committer on -- there's a feeling of "it's not my home".
  Friedel: How hard is it to get a stackexchange sub domain listed? (Answer: easy)
• how much control will we have over it
• Stack exchange is good but not so much with community building
  Juan:
• Difference between asking and discussing.
• Discourse is better for asking.
• Asking and Discussing could lead to creation for the project.
• We Try to create the FAQ on github
• Mailing lists cannot go away.
• There are people who will only use mailing lists.
• Discourse is meant to replace mailing lists
• There are reasons that people don't want to sign up for services like discourse.
• I probably won't use it too much.
• You can get an enormous volume of messages.
• Maybe a segment of people can be on Discourse.
• May have to anser questions twice.
• Discourse may give us more ability to build a community
• This will be alot more management.
• I don't think they are not using github issues because they don't like github.
• It's more of a protocol change for contributors to use github.
  whyrusleeping

from community.

thank you @flyingzumwalt for pushing forward on this!

from community.

We finalized this decision. We're going to use discourse. All the info is at https://github.com/ipfs/community/blob/master/decisions/community-forum-platform.md#decision

from community.