Now that tickets are selling for 32c3. So let's discuss

*TODO: *

• who is coming,
• do we want to create an IPFS Assembly(https://events.ccc.de/congress/2015/wiki/Static:Assemblies)
• list any other planning like travel and meeting up
• all your great ideas

IPFS Assembly

We have an assembly, please comment and edit for corrections as I have no idea what I'm doing

https://events.ccc.de/congress/2015/wiki/Assembly:IPFS

Add yourself to the Assembly

1. Create an account on https://events.ccc.de/congress/2015/wiki/
2. Edit your account and add IPFS as part of your activities, everyone is welcome! :D
   

Now that we enforce "signed-off-bys", we'll need to collect them for older commits.

• enable GitCop on all org repos. (oof, can we have a script do this?)
• draft email to contributors
• make list of (commit, author, email, commit gh link) for commits needing signed-off-bys
• make google form
• send out email (only send out after it's been enabled all over)

i'll do most of this but could use help with the enabling GitCop everywhere. if we can script that, it would be awesome.

We've been talking about the idea of making a IPFS meetup (or meetups) while a big part of the team is here. It is time to organize the troops and make it happen! :)

Date - Thursday, July 23th
Fodd - Thai Catering - http://www.kaosamai.com/
Lineup:

• Juan - IPFS
• Jeromy - The guts of IPFS (lots of Code) (+ cool demos)
• Trevor - Docker & IPFS
• Krl IPFS apps
• Next
• Come hack with us (IPFS Seattle Hack Day)

We should write down who's where when, so that we can optimize for meatspace time. Preferrably in some kind of calendar tool.

https://ipfs.io/docs/commands/ has a reference to each command, but the links all are https://ipfs.io# instead of https://ipfs.io/docs/commands/#

So far we've been granting collab access to repos to whoever has been collaborating for a while, and then requests it. I'd love to keep doing that per repo, that way we can scope access (e.g. go-ipfs collabs cant impact node-ipfs collabs) and sub-cultures and ways of working can be independent. this is perhaps important because different projects (and languages!) have different cultural collaboration styles/rules.

Basically, if you want access to a repo, ask me for it and you'll likely get it (except maybe a few repos)

If this is annoying to people though, can consider one big org where everyone has R/W on everything, except a few "for release" repos that we PR into for code that ships (because at some point released code will have to be security audited, etc). open to discussion on all this.

Please add yourself to the list of people in https://github.com/ipfs/community#people if you wish to be listed :)

@whyrusleeping
@cryptix
@mappum
@briantigerchow
@mildred
@chriscool
@travisperson
@hosh
@tv42
@zignig
@dylanPowers
@dborzov
@cleichner
@Luzifer
@ebuchman

And everyone else i forgot!

Looking at waffle.io. It looks very promising. I played around with the multi-repo linking which isn't perfect but it works. I'm currently waiting upon the creation of ipfs/ipfs to act as a root repo for the IPFS projects.
Tasks for https://waffle.io/ipfs/ipfs:

• Get me permissions to ipfs/ipfs
• Link other repos to ipfs/ipfs
• Figure out how to prioritize issues/decrease noise

I signed up IPFS as a project supporting https://savecrypto.org/ -- please sign and/or get your orgs to.

Issue for organizing meetups in the San Francisco area. Comment here if you'd like to organize one.

All meetups will be announced on the meetup page: https://www.meetup.com/San-Francisco-IPFS/events/261077320/

Was:

@diasdavid and I will be in SF/PA from 10/19-10/24. We will host a meetup, likely on 2015-10-20 as I cannot do any other day in the range. Location + Time still TBD. Will use this issue to coordinate.

Would someone with an @ipfs.io email account please register and spawn an IPFS - Slack room?

Hey Everyone!
I would like to have some common hours on weekdays where everyone is online and available. Working distributed is hard, and even more so when nobody is around to answer questions when you have them. I'm thinking a span of three to four hours, possibly 16:00Z to 19:00Z (plus or minus an hour either direction). This is already the time we do sprint checkins, So I think its fairly reasonable to ask everyone to be 'online' during this time.

Thoughts? Discussion?

Hi everyone,

I've been following the progress of IPFS for many months, but this is actually my first time interacting with the IPFS community on GitHub. 😄

You might know me from my involvement in the SAFE Network community.

I want to organize one last meetup for the SAFE Network Montreal meetup group before the end of the year and I thought it would be really fun to invite the IPFS community to join us!

Date and time: Tuesday, December 8, 2015 from 6:00 PM to 9:00 PM

Location: On the second floor of the Bitcoin Embassy

RSVP: Facebook event

There will be two presentations: one about the SAFE Network and one about IPFS.

The first presentation will be given by myself. I will talk about the SAFE Launcher, the SAFE Network API and the upcoming RFCs.

The second presentation will be given by @cloutier and @didiercf. Half of their talk will be about IPFS and the other half will be about ipfs.pics, an IPFS app that they built together.

If you miss the event, you'll still be able to watch the talks because I will upload them to Youtube a few days later.

You can read the full description of the meetup here.

I have one question for all of you: do you know any IPFS enthusiasts who live in Montreal? 😃

I suggested in irc earlier that it would make sense to have one place for the IPFS community to discuss and share, instead of having the current mix of different github repos + mailing list. Similar to how Maidsafe and rust do it my suggestion is using a discourse instance for this.

Extract from IRC below:

[8:02pm] dignifiedquire:
richardlitt: victorbjelkholm the issue is exactly this, too many places and especially people new to the people don’t have a single place to ask questions/check announcements/view already answered things
[8:03pm] pjz:
need like an ip{f,n}s stackoverflow
[8:03pm] dignifiedquire:
github is great for bugs, and irc is nice for chats but a forum is much better for proper community building
[8:03pm] victorbjelkholm:
maybe we should write a distributed forum on ipfs that collects all the question from different github repos
[8:03pm] victorbjelkholm:
one git repository = one forum section, everything is stored in ipfs
[8:03pm] ogzy:
pjz: i mean when i enter https://gateway.ipfs.io/ipns/QmfGaKQwDPjjcigBfHm7584M4yzqyRn536yePBALRcJaEe to the browser what happens?
[8:03pm] richardlitt:
victorbjelkholm: I think that would work well.
[8:04pm] richardlitt:
dignifiedquire: I'm not sure that a forum would make there be less places, unless we shut down FAQ
[8:04pm] dignifiedquire:
which would be a great project, but I don’t think we should fall into the trap of trying to do everything at once and just use a working solution like discourse for now until we have something ready that is on par in terms of feature
[8:04pm] cemerick left the chat room. (Ping timeout: 240 seconds)
[8:04pm] victorbjelkholm:
pjz, stackoverflow would just be for q&a. What I think dignifiedquire (and me, in case he agrees) is after is a place where you can have discussions
[8:04pm] richardlitt:
support could be shut down; maybe we could just tag FAQ questions as 'support' questions instead
[8:04pm] jamie_k left the chat room. (Client Quit)
[8:05pm] victorbjelkholm:
jbenet, what terminal are you using normally?
[8:05pm] richardlitt:
Forums really aren't all that different than GitHub issues; the difference is that people aren't used to using GitHub issues as discussions
[8:05pm] victorbjelkholm:
re victorb/ipfscrape#6
[8:05pm] victorbjelkholm:
richardlitt, well, a github issue gets completed at one point or another. forum threads tends to be locked because of breaking the rule, or live on forever
[8:06pm] richardlitt:
victorbjelkholm: No, that's just a convention for bugs. There's no reasons to complete a question issue
[8:06pm] dignifiedquire:
richardlitt: yes and no, it’s much easier in a forum to organize things, e.g. things like sticky topics at the top, subforums, tags etc
[8:06pm] richardlitt:
dignifiedquire: sticky topics is a good point, as are subforums and being able to add your own tags
[8:06pm] dignifiedquire:
also don’t underestimate the importance of using things people are already used to
[8:07pm] dignifiedquire:
it lowers the entry barrier, especially for non-tech people who are trying to get to know your project
[8:07pm] richardlitt:
dignifiedquire: agreed
[8:07pm] dignifiedquire:
we are used to using github day in and out, but a lot of people are not
[8:07pm] richardlitt:
I'm not actually advocating against one, I'm just leery of adding another venue to fix the "we have too many venues" problem
[8:07pm] ogzy:
pjz: and istead of using gateway.ipfs.ip/ipns, can it be also used a peer ip?
[8:08pm] richardlitt:
The best way to proceed here is to unironically open a GitHub issue about it on ipfs/community
[8:08pm] dignifiedquire:
if we do it, we should shutdown as much of the other venues and migrate them over
[8:08pm] richardlitt:
dignifiedquire victorbjelkholm would you like to do that?
[8:08pm] dignifiedquire:
[8:08pm] richardlitt:
Well, we could shut down the google groups, FAQ, and Support.
[8:08pm] dignifiedquire:
sure I can create an issue, will paste the the irc chat in there

Hey Everyone, would be great if we directed more people to ask Qs in the FAQ repo, or move the answers yourself. it's a much better resource for newcommers than irc logs. https://github.com/ipfs/faq/issues

thanks!
❤️ jbenet

https://github.com/ipfs/community/blob/master/contribution-guidelines.md has link from text git commit hook to link https://github.com/ipfs/community/blob/master/tools/hooks/commit-msg which gives a 404.

Can someone make a map for ipfs/community with our general locations? (i.e. city).

Bonus points if it tracks the peer.ID of a node we can individually configure via a file on github or ipfs :)

Basically, the webui connections map, but with a given set of peer.IDs instead of the routing table.

@krl can you post here once the connections app is extracted and works?

Proposing moving information about developer tools from ipfs/ipfs/project-directory.md to ipfs/community

If you are living around Paris, France, or if you are sometimes going there, and if you are interested in organizing an IPFS Paris Meetup group, please comment on this issue or contact me.

For your information I already co-organize the git Paris Meetup group:

http://www.meetup.com/fr/git-Paris/

I started it a few weeks ago with some people who are also organizing the very successful Docker Paris Meetups and other Meetups.

Hello IPFSers!

The IPFS Project is growing, and so is the number of people hanging out at the sprint meeting. At last week's hangout, we sadly left many people out.

I had three goals for the Spring Hangout:

a) Give quick synchronized updates on progress. It helps build team rapport.
b) Make space for real-time high-throughput discussion of open questions.
c) Have some regular face-to-face interaction. It's good for humans and communities :)

(a) and (b) are getting hard with so many people, touching so many different areas. At the same time, we've observed that it's actually most useful to sync about things via discussion on irc / github or dedicated topic hangout. And (c) is hard to do when you leave people out :(

Also, we've been discussing sprint things before breaking out into groups to have more detailed discussions. Usually the important sprint items appear at those discussions, and then the sprint list is finalized at the end of the day.

So, thinking of moving to this (let's try this for this week):

On monday, we have three parts:

• Part 1: restrospective: go over last sprint and dicuss what got done, etc. kick off etherpad (async on irc).
• Part 2: per-topic sync discussions / hangouts (sync/async) (more below)
• Part 3: by evening, finalize sprint list (turn etherpad into an issue)

PLUS! A Weekly Community Hangout \o/ - more below.

Topic Discussions

We've naturally fallen into discussing certain topics at high throughput realtime, like node-ipfs, bitswap, and so on.

I figured it would be good to make space during monday for non-overlapping discussions on various topics. Happy to add more here, but so far the things that jump out at me are:

• go-ipfs
• node-ipfs
• testing + ci
• protocol specs
• apps on IPFS
• bitswap (ml)
• data structures
• infrastructure

Weekly Community Hangout

This is more to talk about quick community news, high level direction for the projects, status updates, show off cool hacks, have people meet each other, introduce new people, and in general just hang out.

This is like a short Meetup, or "an all-hands" (or TGIF for those familiar). I would love to experiment with different things, like hanging out in various virtual worlds, VR, video, and so on (more on this later). The time for this will be tricky, because it is towards the end of the week.

Many distributed companies get away with Friday @00:00Z (that's Thu-Fri, and Thursday at 5pm PDT). This leaves people's Friday night plans intact :) though it is 00:00 or 02:00 in Germany -- then again, everyone's around till very late anyway!

I do see a lot of people around on other days (Sun/Mon) too. So open to different times. The goal is to find a good time that works for everyone and is fun, not a problem to join.

Other Distributed Tools

• https://sqwiggle.com/ - could work well for the Async sprint meeting, and to just have a channel. Not public :(
• https://idonethis.com/ - could work well instead of sprint checkins + to keep everyone appraised of what's up without having to sift through the irc channel.
• http://www.worldtimebuddy.com/ - easy TZ conversion

The history stopped being logged to botbot.me last night and .tell and !pin do not work anymore

We need a clear way for IPFS community to organize, or at least some guidelines, so that people that want to host an IPFS meetup or be part of one can find it and be informed of when it is happening.

We've looked into attending.io and meetup.com, both have pros and cons, but none lets us create a succinct and clean experience.

@RichardLitt you have been developing a lot of the materials, calendars and resources for the IPFS community, would you be able to make this happen? I feel that a guideline plus a community map (#39) added on ipfs.io could be something really good.

Read up on http://huonw.github.io/blog/2015/03/rust-infrastructure-can-be-your-infrastructure/ -- i like the ideas presented there. in particular,

• the "testing and merging PRs one by one" is a good idea. wonder if rebases them... that may be too much to ask :D
• the highfive assignments of PRs to maintainers so that new contribs dont feel alone

I'm interested in organizing an IPFS Meetup in Washington, DC.

My comprehension of the program structure is not to the point I'd likely be effective trying to lead a discussion, so I'm currently hunting for collaborators.

Idea.

Many times there's random help I need with things -- e.g. tasks I'm not the best at, that others may be able to or want to help with. This is across repositories (e.g. the blog, or webui, etc). And often people willing to help are not aware of (or following) those repos.

So, what if we had a help-wanted repo (or an issue in this repo), that everyone in the community watches. We can encourage people who want to contribute to watch it. Then, we can post to it about small things (referencing other issues if needed, etc) whenever we need help handling something.

thoughts @whyrusleeping @cryptix @wking @dylanPowers

What

We should be more prominent about how we deal with security issues. Currently, there is a security section in the CONTRIBUTING.md file in this repo. It is the first section, and all IPFS repositories ought to point to this file, anyway - however, they currently do so by linking through their own contribute files, which adds friction for anyone who might have a security concern to follow.

I'm not sure that this is good enough. We could add a Security.md file, and link to it. I suggested this to some people early today, but after an extensive search, I couldn't find any one else who really does this on GitHub, which means that it is unlikely people will be looking for it. As well, I think that security concerns can really be summed up in only one paragraph, and are unlikely to change. I think a better solution is to do what Docker does. Immediately under the description of Docker in their main Readme.md they have a Security Disclosure section, outlining that no issues should be opened which might compromise current versions.

Suggested Next steps

• Add a security section to ipfs/go-ipfs/CONTRIBUTING.md.
• Add a security section to ipfs/ipfs/README.md.
• Add a security section to ipfs/go-ipfs/README.md.

I may be wrong about the security section changing. If so, we can link to a Security.md in this repo. Here is the current section, in it's entirety:

Security Issues

The IPFS protocol and its implementations are still in heavy development. This means that there may be problems in our protocols, or there may be mistakes in our implementations. And -- though IPFS is not production-ready yet -- many people are already running nodes in their machines. So we take security vulnerabilities very seriously. If you discover a security issue, please bring it to our attention right away!

If you find a vulnerability that may affect live deployments -- for example, expose a remote execution exploit -- please send your report privately to [email protected], please DO NOT file a public issue.

If the issue is a protocol weakness or something not yet deployed, just discuss it openly.

https://github.com/ipfs/ipfs/blob/master/CONTRIBUTE.md does not link to ipfs/community/contribute.md, and I think it should.

I also think that it and https://github.com/ipfs/go-ipfs/blob/master/contribute.md have content which should be merged. So, I think I should rewrite them both to make them more project specific, and take out overlapping statements and put that into ipfs/community/contribute.md. Opening this here to see if there is consensus on this before I open PRs.

We're designing some ipfs swag (hoodies, stickers, socks, etc).

There needs to be a section in the contribution guidelines that describes how we have the hard constraint that all commits should pass, so that git bisect is very easy to run.

Brought up in ipfs/kubo#1239 (comment)

I just did my first two PRs to go-ipfs, which requires a license and sign off. I ran the script, but am unsure if I really ought to be force pushing, and whether gitcop is OK with that. The amending commits doc doesn't mention force pushing at all.

Should it? I think a message saying the following would be good: "If your first PR was caught by GitCop, run the script, and force push to fix the issue. Only do this if your PR has not been merged yet."

So, we are (finally!) putting on the schedule some dates for our {Mesh, Hack}/{RoadTrip, Train} to Portlandia, OR :)

We have two options currently and would love to know how would it work best for you, options are

• Sun 19th to Tue 21th or Wed 22th
• Sun 26th to Tue 28th

How does these dates sound, @kyledrake btw, @maxogden, @bcomnes @caseorganic ?

UPDATE - Plan

Monday

• 7:25am - 11:05am - Seattle -> Portland on the Mesh Train (501 Amtrak Cascades)
• Meet with Kyle
• Probably work from CTRLH?

Tuesday

• Start hacking early at CTRLH
• Consider going to the Kubernetes launch
• Meet up Puppet Labs OSCON 2015 "Open" House, promotional code is Attendee

Wednesday

• Juan gets the train back to Portland
• Spend the day working with Amber and Kyle
• IPFS meetup at CTRLH

Thursday

• 8:20am - 12:00pm - Portland -> Seattle Mesh Train (500 Amtrak Cascades)
• IPFS meetup at Seattle's Impact Hub

I know that there are more pressing issues in the project: I am writing this just as a suggestion for years to come, not something that requires immediate attention :-)

Right now IPFS community does just fine with Google Groups, but I feel it may not be enough when community (and general interest in project) gets bigger.

Main issues to anticipate with Google Groups in future:

• Web interface is not a first-class citizen (let's be honest, it is still the email-first solution), which may scare non-technical people off from asking questions or simply browsing old conversations and learning in the process. IRC channel (and its web logs) is actually more user-friendly to join and participate right now, which says it all ;-)
• Lack of categories and tags results in a mixed bag of discussions, which in turn makes filtering and participation really hard
• Google stopped improving Groups for some time already, which is a bad sign: history had shown they may decide to kill it at some point (just like they did with Reader, Wave, and a long list of other services). So migration from Groups may be forced anyway, I guess it may be better to do it sooner than later.

It may be a good idea to solve these problems before it impacts community's communication and productivity.

Possible solution: replace Google Group with self-hosted Discourse instance
(eg. https://discuss.ipfs.io).

Discourse is an open source Internet forum software that empowers communities by giving them state of the art discussion platform. It is fast, reliable, and used by big names such as Docker, Ubuntu or even Twitter.

A quick overview of features can be found at:
http://www.discourse.org and http://www.discourse.org/about/

Please check it out before reading further.

I'll just hint at some features that may be especially useful for us:

Multiple login options

Users can register and login with Github, Google, Facebook, Twitter or a regular login and password.
The friction and hassle is minimal. The only requirement is a working email.

Code Syntax Highlighting

I feel this would make discussions around code much easier.
Discourse uses https://highlightjs.org which supports various languages (including Go) and configuration file formats. Support for specific languages can be enabled/disabled by admin.

Oneboxing

What is Oneboxing? http://try.discourse.org/t/what-is-a-onebox/276

Links to most of Github resources are whitelisted by default and oneboxed quite nicely.
Even the line highlights are supported (example).

Mailing list mode and responses via email

Users can choose what kinds of notifications are sent to them via email (watching/tracking topics, @mentions, etc).
It is also possible for a user to enable mailling-list mode in which every new post is sent via email (same a Google Groups).
They can respond via email too (same as for Github's issue notifications).

This gives a great flexibility and should make both web-native and email-native folks happy.

Try it

There is a special sandbox instance where you can safely create disposable posts:
http://try.discourse.org

Installation and Maintenance

Discourse is a dockerized application (user data is kept outside of docker image), so as long as you can run docker you can install it.
This is a good place to start. Generally these generic steps are enough to have it up and running.

Backups are automatic (good practice is to set up copying daily .tar.gz to other machine).
Updates can be performed via ssh (cd /var/discourse/ && git pull && ./launcher rebuild app) or web gui at /admin/upgrade.

I am maintaining internal instance at work and it is really easy to run once it is set up.
If IPFS project chooses to use Discourse, I'd be glad to help with initial setup and configuration.

IPFS Ideas for Discourse itself

I think that at some point IPFS could be used as a storage backend for mirrored images and post attachments or even encrypted backups and Discourse could provide hints to browsers about IPFS URIs (ipfs/ipfs-companion#16).

We could also create onebox solutions for IPFS URIs which could be included upstream to improve IPFS interop across all discussion communities.

Many people in the IPFS community are going to CCC and Battlemesh in August 2015. This issue is for coordinating plans.

(We will likely overlap / travel along with our node and CJDNS friends)

IPFS Berlin Meetup

Hey Everyone, very last minute we're organizing an IPFS Berlin Meetup.

It is tonight (Thursday 08-27) at 20:00 at c-base (location). Sorry for the short notice! But come hang out!

c-base @ 20:00
Rungestraße 20
10179 Berlin

The format will be straight forward:

• 10min - "What is IPFS" from @jbenet (hopefully can skip if most people know)
• 10min - Install IPFS + 5min basic demo @jbenet
• 40min+ - Demos! \o/

Post below if you would like to demo something. @lgierth, @krl, and I have plenty of stuff, too. And feel free to bring any burning questions!

Cheers,
Juan

@masylum, @victorbjelkholm told me you are organizing an libp2p hackathon for next week? Is there a public plan? I was thinking that maybe, depending if it is next week or the other, I could try to swing by and say hi to NodeConf Barcelona too :)

Hey everyone -- @jamescarlyle and I organized a meetup tonight, after the Ethereum Devcon1.

(Inaugural) IPFS London Meetup

• Time: Nov 10 at 5:30pm
• Location: The Grocer at 3 Crispin Pl (Spitalfields market)

We're happy to send some IPFS stickers to hackerspaces. Just let us know what address and whom to ship them to.

Some users have expressed desire for a signup-style newsletter. We will have to do this eventually.

We should have a guide for creating repositories, and for standardizing READMEs for all IPFS repositories.

Each repository should have:

• A clear description in the GitHub description field.
• A clear description (which can be longer) in the README.
• A license - potentially MIT, or CC0, depending on the type of organization. Having different licenses is OK.
• A contribute section in the Readme for discussion repositories, or a contribute.md if there are more specialized instructions (for instance, language styles, which should link to a language contribution guide in this repository.
• A usage section (if appropriate)
• A link to places to ask questions - this can be ipfs/community, too.
• Buttons!!!

What do you think are necessary? I'll open a PR after some discussion.

Things like community advocate, go developer, supreme interplanetary ruler, etc... That will give anyone who reads the list a better idea of what the people listed do.
Say aye, if you also think this is a good idea.

We will pin all hashes posted here that contain battlemesh media and assets. Just post a message like this:

@ipfsbot pin

We should have a nodejs and javascript guidelines file to link to from all IPFS js repositories. I can't seem to find a good example of any JS guidelines in our current repositories (anyone know of one?), so I think we should hash out what standards we want here, so that we can add that to an eventual file, like we did with Go in #58.

Open questions:

• Standard format? Do we want to conform to ferross/standard?
• Standard testing framework?
• Standard test coverage needed?

I could build us a comprehensive styleguide given time if needed; plenty of good examples on RichardLitt/awesome-styleguides to work from.

cc @diasdavid @jbenet

Just some apps I've found around the interwebz that use IPFS. I'll try to keep this list updated in order of activity. Make a comment to be added and I'll comment when I find something. Feel free to subscribe to stay up to date.

• git-ipfs-rehost: A script to rehost your git repos in ipfs.
  Author: Jeromy Johnson
• IPFS playback support in Playback video player. This allows casting a video in IPFS to a Chromecast.
  Patch Author: Juan Benet
• ipfs-firefox-addon: A Firefox addon for redirecting gateway.ipfs.io links to your local gateway.
  Author: Marcin Rataj
• IPFS Linux Init Daemon: For anyone running ipfs on a server somewhere (like an rpi in your living room), I've created a script that will install the ipfs daemon as a Linux system daemon. No more screen processes! :D
  Author: Dylan Powers
• IPFS Gateway Redirect: A Chrome extension that allows you to access gateway.ipfs.io urls the way they were meant: from your locally running ipfs daemon.
  Author: Dylan Powers
• ipfs-userscript: Browser userscript for redirecting gateway.ipfs.io links to your local gateway. This should work on any browser that hasn’t had an extension written for it yet and has support for userscripts.
  Author: loadletter
• IPFS Share: An IPFS backed Pastebin / Image Host / File Sharing application.
  Author: Varun Ramesh
• IPFS Event Drop: An app that allows for improved visualization of ipfs events.
  Author: Travis Person
• Cohort: A golang app to preset a threejs interface and get all of its assets out of IPFS.
  Author: zignig

At some point we lost the discussion on copyright and how the DCO works. how it works in a commit is there, but the large discussion we grabbed from Docker's contribute.md is gone. we should add it back so people can understand what it means legally.

Following https://twitter.com/ipfsbot/status/650873591400112128 I've created again the Portland IPFS meetup on meetup.com http://www.meetup.com/IPFS-Portland.

The last one was lost due to meetup.com policies (they have a 72 hours policy to delete the meetup if they find the information of the meetup incomplete, and since the notification went to the ipfsbot account, no one checked it on time :( )

@kyledrake To add you as a co-org, I need you to join the meetup first :)

we should have a doc that explains the label scheme. so far it's basically:

• blue: topic / subsystem
• light red (important topic): security things
• red (very important): bugs!!
• orange (important): cleanup / refactor things
• light green: the difficulty level
• dark green: testing
• yellow: documentation
• gray waffle labels: used by https://waffle.io/ipfs/ipfs

notes:

• it's very ad-hoc, so no strict science.
• name should be understandable by themselves. for example, use "difficulty: medium" instead of "medium".
• use color to denote groupings, and perhaps some meaning (e.g. red is {bugs, problems, errors, races})

Copenhagen needs to gather all IPFS enthusiasts so we can talk about this awesome technology and organize projects built around it.
Anyone interested please join us here.

Hope to see you soon.

:) Teo

Thinking I want this out Friday. I'll see if I can find some new projects involving IPFS. Primarily I think I'll want to do an introduction to the new repository layout and all the tools we're using.