Skip to content

Meeting 2015 10 08

Jump to bottom Edit New page
JanKusanagi edited this page Oct 9, 2015 · 14 revisions

Call for meeting

https://identi.ca/cwebber/note/riVqREL9Sbq_lENokDSQOw

9AM PDT, Convert to your time

Agenda

(Add your items here!)

..Added the M points to the agenda, I'll try to be online on time, Menno

Log

The meeting took place in IRC #pump.io channel in Freenode.

Here is the log:

[18:03] <larjona> ================== LOGGING... ===================

[18:04] <paroneayea> and elf-pavlik made a reasonable request:

[18:04] <evanpro> Hooray

[18:04] <paroneayea> oh

[18:04] <evanpro> What request is that?

[18:04] <paroneayea> it's the first agenda item

[18:04] <paroneayea> Move to ActivityPump (and ActivityStreams 2.0)

[18:04] <paroneayea> but elf's request was

[18:04] <strugee> hey evanpro!

[18:04] <paroneayea> <elf-pavlik> paroneayea, what do you think about including short update about work in Social WG as part of Move to ActivityPump (and ActivityStreams 2.0) ?

[18:04] <paroneayea> so yes, let's start with that.

[18:04] <paroneayea> btw, it's okay to jump in at any time, as long as on topic

[18:04] <paroneayea> #mediagoblin people know I have a tendency to textwall, so please don't be afraid :)

[18:05] <evanpro> All right

[18:05] * elf-pavlik paroneayea, tsyesika , evanpro, ben_thatmustbeme, aaronpk and me - all participate in W3C Social WG

[18:05] <paroneayea> yes

[18:05] <paroneayea> there are a few standards movements there, but the first of which is activitystreams 2.0

[18:05] <paroneayea> http://www.w3.org/TR/activitystreams-core/

[18:06] <paroneayea> basically an update to AS 1, which pump.io currently uses in its existing API

[18:06] <paroneayea> and since the existing pump api uses AS 1, time for an update to AS 2... amongst other things, yeah? :)

[18:06] <evanpro> Right

[18:06] <paroneayea> so the existing pump.io api:

[18:06] <evanpro> Everything in pump.io is AS1, input and output

[18:06] <paroneayea> https://github.com/e14n/pump.io/blob/master/API.md

[18:06] <evanpro> So, hold on

[18:06] <evanpro> Let's discuss this first

[18:06] <paroneayea> okay :)

[18:07] <evanpro> Is it time for an update?

[18:07] <evanpro> The AS 2 standard isn't at CR yet

[18:07] <evanpro> It may never be

[18:07] <paroneayea> it's possible that it might not, but I'm optimistic

[18:07] <evanpro> Like, that's a distinct possibility

[18:07] <evanpro> OK, that's good to hear

[18:07] <elf-pavlik> It may get to CR but until that it can have significant changes

[18:07] <strugee> evanpro: remind me what CR stands for?

[18:07] <paroneayea> I"ll comment on that in a sec, but

[18:07] <evanpro> But we have a few thousand people using this network

[18:07] <elf-pavlik> CR - Candidate Recommendation

[18:07] <evanpro> Candidate recommendation = CR

[18:07] <strugee> thanks

[18:07] <paroneayea> some people here don't know what the new thing we're working on are, so let me drop 2 links so other people can catch up

[18:08] <elf-pavlik> WD - Working Draft

[18:08] <evanpro> Sounds great

[18:08] <paroneayea> http://w3c-social.github.io/activitypump/ proposed spec to replace existing pump.io api, standardize it

[18:08] <strugee> elf-pavlik: I remembered most of them, just not CR :)

[18:08] <paroneayea> and uses AS 2.0

[18:08] <evanpro> Sorry, but "time for an update" seems to be jumping the gun to me

[18:08] <paroneayea> evanpro: right

[18:08] <paroneayea> evanpro: okay, so that's the new spec tsyesika, evanpro, oshepherd, and I have worked on

[18:08] <paroneayea> using new AS 2.0

[18:08] <evanpro> Yes

[18:09] <paroneayea> so evanpro's question is a good one, do we want to start updating pump.io now?

[18:09] <strugee> I haven't read either spec so I don't know how similar they are but we could implement support, pref'd off

[18:09] <paroneayea> AS 2.0 hasn't hit CR yet

[18:09] <evanpro> So, if we move to this, we will be the first software to go to it in production

[18:09] <paroneayea> one of the things holding AS 2.0 from CR I think is the lack of test suite, right evanpro ?

[18:09] <evanpro> One of the main reasons we're in this meeting is because we're pretty stretched in terms of development resources

[18:09] <evanpro> paroneayea: yes

[18:09] * elf-pavlik WD - http://www.w3.org/2015/Process-20150901/#working-draft

[18:09] <paroneayea> I basically volunteered to do that in this week's socialwg meeting ;p

[18:10] <paroneayea> yes, many people here are stretched thin :((

[18:10] <evanpro> I know

[18:10] * elf-pavlik CR - http://www.w3.org/2015/Process-20150901/#candidate-rec

[18:10] <evanpro> Which, we need to be a little bit strategic

[18:10] <evanpro> Sorry to be playing devil's advocate but I want to make sure we're doing this the right way for the right reasons

[18:10] <paroneayea> evanpro: maybe we need to get the gears turning on pump.io generally before we start the AS conversion?

[18:10] <paroneayea> is that what you think?

[18:10] <evanpro> I'm generally in favour of moving to AS 2

[18:10] <paroneayea> er AS2

[18:10] <evanpro> paroneayea: that's another possibility

[18:11] <paroneayea> evanpro: note that getting started on pump.io is our next topic :)

[18:11] <paroneayea> just fyi

[18:11] <evanpro> OK, cool

[18:11] --> Nemno has joined this channel.

[18:11] <larjona> well, why not offering a branch that people can deploy in new nodes, just to try?

[18:11] <Nemno> o/

[18:11] <paroneayea> larjona: I think starting things as a new feature branch is the right move

[18:11] <evanpro> larjona: good question

[18:11] --> ninguno has joined this channel.

[18:11] <paroneayea> it should not happen in master

[18:11] <paroneayea> hi Nemno

[18:11] <evanpro> larjona: let's discuss

[18:12] <evanpro> What would that mean for the network?

[18:12] <larjona> a different network

[18:12] <evanpro> We'd have to build in multi-level federation

[18:12] <strugee> since we're all limited on time we could also just say that we'll defer the decision and focus on bugs and polish ATM

[18:12] <evanpro> Like, "Does this server accept AS2? Send it AS2. Otherwise, send it AS1."

[18:12] <evanpro> strugee: That might be a good next step

[18:13] <strugee> that'd (maybe) give the spec time to come closer to CR

[18:13] <evanpro> larjona: right, the other thing is to not build in any compatibility and have a separate network just for AS2 stuff

[18:13] <paroneayea> it might be that people also have different interests here, and we should work with them on what they're interested in

[18:13] <larjona> evanpro I was thinking about the second (no compatibility)

[18:13] <evanpro> paroneayea: true

[18:13] <paroneayea> eg, if I contribute to pump.io it's mostly for advancing activitypump as a standard

[18:13] <evanpro> so, one argument in favour of starting work on AS 2

[18:14] <evanpro> Is that we'd be the first platform to support AS 2

[18:14] <evanpro> So people who wanted to experiment with AS 2 would be likely to be drawn to pump.io...

[18:14] <strugee> paroneayea: where's polish stuff on your priorities list? e.g. fixing some of the web interface problems

[18:14] <evanpro> ...and may help with development and community efforts

[18:14] <paroneayea> evanpro: it would be good to "prove" as2 also

[18:14] <strugee> just wondering

[18:14] <larjona> (if we deploy pump servers faster than the gobliners)

[18:14] <evanpro> paroneayea: right

[18:14] <paroneayea> strugee: polish is high on my community priorities list, but not on my personal hacking list.

[18:15] <paroneayea> eg, I want it to happen, am happy to guide the community

[18:15] <elf-pavlik> IMO working on independent experimental branch with test deployments may make sense at least till AS2.0 goes into CR stage

[18:15] <strugee> gotcha

[18:15] <xmpp-pump> [Jan] seems to me like there aren't many people here, other than evanpro, really familiar with pump.io's codebase, so it would probably be best to transition to community development first, get to know it, and later update the whole thing to the new specs

[18:15] <paroneayea> but will not put in my code time

[18:15] <evanpro> but if it doesn't work well, we are throwing pump.io users under the bus

[18:15] <paroneayea> evanpro: right

[18:15] <evanpro> pump network users are a really resilient bunch

[18:15] <paroneayea> evanpro: I think we might need to start things as a feature branch, and "check in" with the community on how it's going?

[18:15] <paroneayea> in a future meeting?

[18:15] <evanpro> paroneayea: that would be really cool

[18:16] <evanpro> paroneayea: this might sound machiavellian

[18:16] <paroneayea> evanpro: and I agree, don't want to throw pump.io users under the bus

[18:16] <evanpro> But we might also build in a poison pill of some kind

[18:16] <evanpro> To keep people from deploying the AS2 branch on the public pump network

[18:16] <paroneayea> evanpro: I would support that in our early stages

[18:17] <paroneayea> as long as there is a way to get an antidote in the future ;)

[18:17] <evanpro> Like you have to start it with bin/pump --i-am-willing-to-mess-up-the-public-network=yes

[18:17] <paroneayea> evanpro: I like that route

[18:17] <evanpro> paroneayea: oh yeah

[18:17] <larjona> I don't see any problem. People can have their node based in the stable branch, and deploy a AS2 node for tests

[18:17] <evanpro> exactly

[18:17] <evanpro> buuuuuuuuuuuuuut...

[18:18] * larjona waits and listens

[18:18] <evanpro> pump.io isn't particularly resilient in the face of deployed changes

[18:18] <Nemno> Make as2 not compatible to as1. Make a 'transport' proxy to make a transition time between AS2 en AS1 possible.

[18:18] <evanpro> Like, if you deploy at mytestdomain.com:8080 and then switch to myrealdomain.com/ it gets all crazy

[18:18] * elf-pavlik https://github.com/jasnell/w3c-socialwg-activitystreams/issues/203

[18:19] <paroneayea> we don't even know what other activitypump incompatibility things might happen in the future

[18:19] <paroneayea> will it still use oauth1?

[18:19] <paroneayea> that's still not clearly defined.

[18:19] <evanpro> Right

[18:19] <evanpro> Nope

[18:19] <paroneayea> so I think we have a good general idea of how to proceed here

[18:19] <evanpro> Or should we take the opportunity to move to oauth2?

[18:19] <paroneayea> right

[18:19] <paroneayea> but we need to figure out how to bootstrap hacking and the community at all

[18:19] <evanpro> paroneayea: if I were to sketch this out I'd suggest the following

[18:20] * strugee has to go

[18:20] <strugee> bye all

[18:20] <paroneayea> later strugee

[18:20] <evanpro> Shoot

[18:20] <evanpro> We lost strugee !

[18:20] <evanpro> Key part of the next step!

[18:20] <evanpro> strugee we need youuuuuuuuuuuuuuuuu

[18:20] <evanpro> B-)

[18:20] <paroneayea> we'll fill in strugee over pump :)

[18:20] <tsyesika> I'm not sure if it's in the spec but micropub and solid folk seem to agree on oauth 2 so we might as well move

[18:20] <tsyesika> I said it made sense at paris and either did or intended to update AP

[18:20] <paroneayea> right

[18:21] <paroneayea> probably yes, though I think AP decisions are out of scope of this meeting

[18:21] <evanpro> There are pluses and minuses

[18:21] <evanpro> OK

[18:21] <paroneayea> sorry, I didn't mean to shoot that down

[18:21] <paroneayea> :(

[18:21] <evanpro> NP

[18:21] <paroneayea> evanpro: go ahead

[18:21] <evanpro> Let's keep up the momentum, I'm enjoying this discussion

[18:21] <evanpro> Oh. Long story short, OAuth 2 is a much broader spec with a lot more options that OAuth 1

[18:22] <tsyesika> indeed

[18:22] <tsyesika> more complicated to implement also

[18:22] <evanpro> So no two Oauth 2 implementations are quite the same

[18:22] <evanpro> tsyesika in some ways it's easier, especially if you use HTTPS

[18:22] <evanpro> but I agree

[18:22] <paroneayea> I wonder if aaronpk has something to say here

[18:22] * aaronpk waves

[18:22] <evanpro> Hi aaronpk

[18:23] <aaronpk> I would argue OAuth 2 is way easier to implement, but yes it's true that two OAuth 2 servers may not be guaranteed to be compatible

[18:23] <evanpro> One nice thing about OAuth 2 is that the discovery mechanism is part of the spec

[18:23] <aaronpk> that said, almost all of the deployed servers have made the same decisions so are actually very similar

[18:23] * elf-pavlik AFAIK aaronpk authored https://indiewebcamp.com/OAuth#Books and runs http://oauth.net/

[18:23] <paroneayea> in many ways this is a good convo to have in the socialwg

[18:23] <evanpro> aaronpk: very few of the servers that are out there have the same requirements as the pump network

[18:23] <ben_thatmustbeme> i'd second oauth2 being much easier to implement

[18:23] <paroneayea> and arguably

[18:23] <evanpro> right

[18:23] <paroneayea> the kind of conversations we should be having

[18:24] <paroneayea> rather than linked data and microformats arguments ;)

[18:24] <aaronpk> give this a read, short intro to how most of them work http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified

[18:24] <aaronpk> evanpro: what sort of requirements? are they documented somewhere? I would be interested in looking

[18:24] <elf-pavlik> aaronpk++

[18:24] <paroneayea> ooh good link aaronpk

[18:24] <evanpro> aaronpk: well, for one, clients have to discover the OAuth endpoints at each server

[18:25] <evanpro> They can't depend on a single API server existing

[18:25] <paroneayea> (so I'd like to put a cap on this conversation of federation details to the half hour mark, because we have people here who want to know how to contribute, and I don't want to lose their time, so 5 more minutes)

[18:25] <evanpro> Also, there's key generation

[18:25] <elf-pavlik> one proposal for disco: https://www.tuxed.net/fkooman/blog/as_discovery.html

[18:25] <evanpro> Being able to register for keys in a server-to-server way

[18:25] --> victorhck has joined this channel.

[18:25] <aaronpk> ah yeah, that's one of the extensions

[18:25] <evanpro> aaronpk: it sure is!

[18:26] <evanpro> but most implementations don't use it

[18:26] --> marxistvegan has joined this channel.

[18:26] <aaronpk> yeah

[18:26] <aaronpk> indieauth solved that by using URLs for everything, so no secrets needed. I wonder if something similar could be done here

[18:26] <aaronpk> indieauth is essentially a "profile" of OAuth 2

[18:26] <evanpro> right

[18:26] <evanpro> We'd need to identify the profile that works for the pump network

[18:27] <evanpro> With an eye to making it compatible with future standardization efforts

[18:27] <evanpro> ANYWAY

[18:27] <evanpro> Back to roadmap and priorities

[18:27] <paroneayea> yes

[18:27] --> band has joined this channel.

[18:27] <paroneayea> evanpro: aaronpk: tsyesika: elf-pavlik: ben_thatmustbeme: can we schedule to talk about this at the next socialwg meeting? this is a really useful conversation and we should be having this convo there

[18:27] <evanpro> I'm not sure

[18:27] <evanpro> That makes sense

[18:27] <elf-pavlik> +1 paroneayea

[18:28] <evanpro> But fine

[18:28] <paroneayea> :)

[18:28] <aaronpk> authentication/authorization was explicitly out of scope of that WG, so mayyybe

[18:28] <paroneayea> okay, I really want to move on to how to contribute

[18:28] <larjona> Did we agree in something about AS2?

[18:28] <paroneayea> aaronpk: you're right

[18:28] <larjona> May I text a proposal?

[18:28] <paroneayea> it's difficult, because that makes things impossible

[18:28] <evanpro> larjona: that might be the next step

[18:28] <evanpro> "Roadmap"

[18:28] <evanpro> So if I were going to sketch out a quick roadmap

[18:28] <evanpro> It'd be this

[18:28] <evanpro> 1) Review and accept/reject existing PRs

[18:29] <evanpro> 2) Review and fix existing bugs

[18:29] <elf-pavlik> we agreed that party acting as API client will have (somehow) a Bearer Token http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html

[18:29] <evanpro> 3) Start work on UI changes (possibly using Steven Sekula's branch as a foundation)

[18:29] * elf-pavlik shuts up ...

[18:29] <evanpro> elf-pavlik: hey, could you can it?

[18:29] <evanpro> Thanks

[18:29] <evanpro> 4) Work on AS2

[18:29] <paroneayea> that's a great roadmap

[18:30] <evanpro> 1 and 2 are important jobs that I haven't had a chance to do

[18:30] <larjona> evanpro,I think 4 can be in parallel

[18:30] <paroneayea> note that much of this can also happen in parallel

[18:30] <paroneayea> yes

[18:30] <larjona> since paroneayea will not fix bugs

[18:30] <evanpro> paroneayea: possibly

[18:30] <evanpro> I'd argue that 1 and 2 will give the kind of understanding of the codebase that makes 3 and 4 possible

[18:30] <paroneayea> evanpro: sure, and that's probably true

[18:30] <paroneayea> it's a good general roadmap, and if parallelization naturally happens

[18:31] <paroneayea> we shouldn't hinder it, and should help it along

[18:31] <evanpro> Right

[18:31] <paroneayea> but I agree that 1 and 2 are a good way to bootstrap

[18:31] <paroneayea> so, we're moving right into the next topic, should we formalize that? :)

[18:31] <evanpro> Yes!

[18:31] <larjona> about the AS2 work

[18:31] <paroneayea> oh

[18:31] <paroneayea> actually you just hit 2.1

[18:31] <paroneayea> 2) Getting started on pump.io development

[18:31] <evanpro> I have one more thing to say about it too

[18:31] <paroneayea> and 2.1) (M) Roadmap with priorities

[18:31] <paroneayea> :)

[18:31] <evanpro> about AS2

[18:31] <evanpro> design-wise

[18:31] <clacke2> \o

[18:32] <evanpro> clacke2: is that a raised hand?

[18:32] <evanpro> or a wave?

[18:32] <clacke2> oh sorry, just hello. been lurking since :12 catching up on convo

[18:32] <evanpro> Gotcha

[18:32] <evanpro> OK, so one last thing about AS2

[18:33] <evanpro> Which is that there are two possible ways to implement it

[18:33] <evanpro> Currently pump.io uses AS1 both for API and for internal storage

[18:33] <evanpro> It jams AS1 objects into a database

[18:33] <evanpro> So we can upgrade in two ways

[18:34] <strugee> I'm back

[18:34] <evanpro> The first is to look for AS2 objects as they come in, convert them to AS1 objects, and then let all the processing code handle and store them

[18:34] <evanpro> And finally when it's time for output, re-convert back to AS2

[18:34] <evanpro> This is probably the fastest way to do it

[18:35] <evanpro> The other possibility is to change to use AS2 as the internal storage format

[18:35] <elf-pavlik> this way pump instances would only federate with each other, not all AS2 can have AS1 representation

[18:35] <paroneayea> elf-pavlik: what's a blocker on representation of AS2 as AS1 representation?

[18:35] <evanpro> elf-pavlik: hey, thanks for your help

[18:35] <paroneayea> I wasn't aware of this

[18:36] <evanpro> That is a useful point

[18:36] <evanpro> However

[18:36] <evanpro> This would be for getting a quick implementation working

[18:36] <elf-pavlik> paroneayea, we can reclycle this issue for clarificaitons https://github.com/jasnell/w3c-socialwg-activitystreams/issues/203

[18:36] <evanpro> Anyway, as I was saying

[18:36] <paroneayea> elf-pavlik: thanks

[18:36] <evanpro> The other possibility is to use AS2 internally

[18:36] <evanpro> And have a compatibility layer for AS1

[18:37] <evanpro> That would require a lot more work

[18:37] <paroneayea> I'm much more interested in that route

[18:37] <elf-pavlik> most issues would come with handling AS2 data which uses extensions http://www.w3.org/TR/activitystreams-core/

[18:37] <paroneayea> though it will probably be the work of whoever does the job

[18:37] <evanpro> As well as having a conversion process for existing databases

[18:37] <paroneayea> to decide

[18:37] * elf-pavlik http://www.w3.org/TR/activitystreams-core/#extensibility

[18:37] <evanpro> elf-pavlik: yeah, that's a really low priority right now

[18:37] <paroneayea> evanpro: ok, thanks for clarifying that!

[18:37] <evanpro> paroneayea: well, that's possible

[18:38] <elf-pavlik> just wanted to point out what one can expect when federating with non pump.io instances

[18:38] <evanpro> elf-pavlik: which don't exist

[18:38] <paroneayea> well, pump.io only federates with pump.io right now

[18:38] <paroneayea> that's a non-issue

[18:38] <aaronpk> is federating with non pump.io servers a priority?

[18:38] <evanpro> not yet, no

[18:38] <paroneayea> aaronpk: it is, come activitypump conversion

[18:38] <paroneayea> and

[18:38] <paroneayea> well

[18:38] <paroneayea> actually

[18:39] <elf-pavlik> mediagoblin ?

[18:39] <paroneayea> it is come mediagoblin federation too

[18:39] <paroneayea> jessica is working on that right now

[18:39] <paroneayea> tsyesika I mean

[18:39] <evanpro> let me say that federating with non-activitypump servers is not a priority

[18:39] <paroneayea> and as I said in the last socialwg meeting

[18:39] <paroneayea> she just landed support

[18:39] <paroneayea> but

[18:39] <evanpro> Yay

[18:39] <paroneayea> for the db conversion

[18:39] <paroneayea> so server to server is coming up fast

[18:39] <paroneayea> mediagoblin is moving to activitypump in theory anyway

[18:39] <paroneayea> so this is a non-issue

[18:39] <paroneayea> we'll deal with that as we go

[18:39] <evanpro> Hey one last thing on AS2

[18:40] <paroneayea> evanpro: ok, onnnnnnne las thing

[18:40] <paroneayea> !

[18:40] <evanpro> Which is that pump.io's internal processing uses a processing queue model

[18:40] <evanpro> So it'd be possible to do something like

[18:40] <evanpro> HTTP request -> [convert from AS2 to AS1 if needed] -> regular handling -> [convert from AS1 to AS2 if needed] -> HTTP result

[18:41] <paroneayea> evanpro: great

[18:41] <evanpro> Those two bracketed parts could be relatively easy to write

[18:41] <evanpro> So I think that's the right way to go

[18:41] <evanpro> OK done

[18:41] <paroneayea> thank you for all that guidance evanpro !

[18:41] <paroneayea> ok, next topic: getting people started on pump.io dev

[18:41] <paroneayea> so, I checked out pump.io and tried to get started

[18:41] <paroneayea> the tests don't run

[18:41] <paroneayea> fully

[18:42] <paroneayea> they stop somewhere mid-tests and hang

[18:42] *** ChanServ gave evanpro op privileges.

[18:42] <paroneayea> that's kind of a blocker for people to get started I think

[18:42] <evanpro> paroneayea: did you run the script first?

[18:42] <paroneayea> evanpro: no, what script?

[18:42] <evanpro> Like it says in the README

[18:42] <paroneayea> evanpro: I guess I didn't read the README :)

[18:42] <evanpro> The script that sets up the hosts

[18:42] <paroneayea> my bad

[18:42] <evanpro> You can't test federation without multiple hosts

[18:43] <paroneayea> hm

[18:43] <paroneayea> it doesn't say this does it?

[18:43] <paroneayea> it says

[18:43] <paroneayea> You can then install the dependencies using npm:

[18:43] <paroneayea> cd pump.io

[18:43] <paroneayea> npm install

[18:43] <paroneayea>

[18:43] <paroneayea> To test the install, run:

[18:43] <paroneayea> npm test

[18:43] <paroneayea>

[18:43] <paroneayea> so that's what I did

[18:43] <paroneayea> no in-between step

[18:43] <paroneayea> so I did read the README! but if there was something else to do, I missed it

[18:44] <evanpro> https://github.com/e14n/pump.io/blob/master/test/hosts.sh

[18:44] <paroneayea> sudo :(

[18:44] <paroneayea> okay I'll try this

[18:44] <evanpro> I think it might be TESTING.md

[18:44] <evanpro> NP

[18:44] <paroneayea> evanpro: we ll maybe that needs to be added to the README

[18:44] <paroneayea> I'll see

[18:44] <evanpro> We can walk through it together and update the TESTING.md file to make sure the instructions are correct

[18:44] <paroneayea> and commit if necessary

[18:45] <-- mnd has left this channel.

[18:45] <evanpro> We may also want to skip federation tests if the /etc/hosts file isn't up to date

[18:45] <strugee> the other problem with tht tests is that some of the modules are deprecated and/or broken

[18:45] <Nemno> @paroneayea had the same experience with the test. Seems my node version doesn't like setTimeout and setInterval. If you clear them before ending the test everything works ok.

[18:45] <strugee> I got most of the tests to run but Zombie turned into a versioning nightmare

[18:46] <evanpro> Yeah it's a hassle

[18:46] <strugee> if you check my fork I committed a couple version bumps to fix some stuff but

[18:46] <evanpro> I think if you use nodejs 0.10 and below it works OK

[18:46] <strugee> we need to evaluate which Node versions we need support for

[18:46] <strugee> yep

[18:46] <evanpro> But there are still some logjams

[18:46] <evanpro> strugee: good point

[18:46] <evanpro> There are also a lot of issues with HTTPS

[18:46] <evanpro> 0.10 doesn't check certs strictly

[18:46] <evanpro> So the HTTPS tests will work

[18:47] <evanpro> But 0.12 does and it flips out

[18:47] <evanpro> Unless you set an env variable IIRC

[18:47] <strugee> huh

[18:47] <evanpro> There's some setup that happens in the travis CI file that might be useful

[18:47] <strugee> I didn't run into that problem IIRC

[18:47] <evanpro> Oh cool

[18:48] <evanpro> paroneayea: another thing we could do

[18:48] <evanpro> Is break the tests up

[18:48] <paroneayea> evanpro: that might be a good idea

[18:48] <evanpro> Like tests that don't need multiple hosts + tests that do need multiple hosts but not HTTP + tests that need both

[18:49] <evanpro> I think martin fowler talks about having a 30-second test suite and a 10-minute test suite

[18:49] <paroneayea> evanpro: that might be wise

[18:49] <evanpro> Another roadmap item that is probably worth considering

[18:49] <evanpro> Is moving to CoffeeScript or ES6

[18:49] <evanpro> But I think that might be farther down the line

[18:49] <paroneayea> probably farther down the line

[18:50] <paroneayea> and I'd prefer considering ES6 over coffeescript

[18:50] <Nemno> 2nd

[18:50] <paroneayea> if we do the latter, it throws out a lot of contributions

[18:50] <evanpro> Why's that?

[18:50] <paroneayea> evanpro: well, lots of patches won't merge at that point, right?

[18:50] <evanpro> How so?

[18:50] <strugee> +1 for ES6

[18:50] <evanpro> Oh yeah

[18:50] <paroneayea> we'd have to merge all patches to move forward

[18:50] <evanpro> No that'd have to be later

[18:50] <paroneayea> basically even to have to consider it

[18:50] <paroneayea> pump.io needs to be in a better state

[18:50] <paroneayea> ES6 is more gradual

[18:50] <strugee> less effort

[18:50] <evanpro> I think the nice thing about coffeescript is that it's a lot more readable for python devs

[18:50] <paroneayea> we don't need to throw out the existing system

[18:51] <evanpro> And Ruby peeps

[18:51] <paroneayea> evanpro: javascript is fine readability wise I think, there are worse things about the language than readability ;)

[18:51] <evanpro> Ha

[18:51] <evanpro> We don't need to have this conversation

[18:51] <paroneayea> yes I agree

[18:51] <paroneayea> so

[18:51] <evanpro> OK let's keep going

[18:51] <paroneayea> I guess the question is, how can we get people going now

[18:51] <paroneayea> tests is one blocker

[18:51] <paroneayea> are there others?

[18:52] <paroneayea> have other people in channel had experiences related to getting pump.io up and running?

[18:52] <evanpro> Time to review patches

[18:52] <strugee> IIRC mostly it was the tests when I forked

[18:52] <strugee> we need to get dependencies up-to-date as well

[18:52] <evanpro> so, strugee

[18:52] <strugee> I checked and some of the modules in use now have security vulns

[18:52] <paroneayea> !

[18:52] <evanpro> strugee: yikes!

[18:52] <paroneayea> well that's pretty important

[18:53] <strugee> yeah :/

[18:53] <evanpro> Yep

[18:53] <strugee> I used nsp

[18:53] <evanpro> So can we start documenting those in Github?

[18:53] <strugee> I didn't want to publicize it for obvious reasons

[18:53] <evanpro> Well

[18:53] <evanpro> That doesn't make them go away

[18:54] <strugee> yeah, I know

[18:54] <strugee> it was on my list to fix, but I wanted to get tests passing first :/

[18:54] <paroneayea> so two major points:

[18:54] <paroneayea> - get tests passing

[18:54] <evanpro> Yeah, that makes sense

[18:54] <strugee> it isn't a trivial bump for some of them (e.g. Express)

[18:54] <Nemno> I had a problem cause i use docker and have multiple sevices on 1 ip. Using Haproxy to handle ssl and the routing of the subdomains... But made a ugly fix (hardcoded) to get it going.

[18:54] <paroneayea> - get dependencies upt o date

[18:54] <strugee> paroneayea: sounds good to me

[18:55] <clacke2> does github support hidden issues? if so, even for free projects?

[18:55] <strugee> clacke2: no

[18:55] <paroneayea> so... I think these are blockers for me to contribute, too

[18:55] <paroneayea> because I'm totally new to node

[18:55] <strugee> you need a private repo

[18:55] <paroneayea> so when I start on a project and it doesn't even run

[18:55] <strugee> be right back, walking to my next class

[18:55] <paroneayea> in a system I'm unfamiliar with

[18:55] <paroneayea> that's kind of hard to do anything

[18:55] <paroneayea> not to mention so little time

[18:55] <evanpro> Right

[18:56] <paroneayea> so I guess the big question is, "who is willing to step up to the plate for it?"

[18:56] <paroneayea> given that I just volunteered to work on tests for activitystreams 2

[18:56] <paroneayea> I have to say "not me"

[18:56] <evanpro> OK

[18:56] <paroneayea> but if someone can do it, I can then start helping with pump.io I think

[18:56] <evanpro> So I'm running the test suite on my computer right now

[18:56] <clacke2> Might I suggest that some security team uses a gitlab.com repo and issue tracker to manage the security issues

[18:56] <evanpro> clacke2: OK, not a bad idea

[18:56] <Nemno> i'll help on the test stuff as far as my knowledge goes

[18:57] <strugee> it works if you use an older Node

[18:57] <strugee> ish

[18:58] <evanpro> Right

[18:58] <strugee> the main problem is Zombie

[18:58] <evanpro> paroneayea: one reason you might think it hangs is that it does some pretty big scaling tests

[18:58] <paroneayea> evanpro: ah, hm

[18:58] <evanpro> strugee: you mean that it uses an old version?

[18:58] <strugee> with everything else there's stuff that could be improved, e.g. replacing simplesmtp(?) with something less deprecated

[18:58] <evanpro> strugee: OK

[18:58] <strugee> evanpro: so Zombie 4.x only works on io.js or equivalent

[18:59] <evanpro> ZOMG

[18:59] <evanpro> Thanks, assaf

[18:59] <strugee> the Zombie in use currently, 1.x IIRC, doesn't work on 0.12

[18:59] <evanpro> Right

[18:59] <Nemno> I'll try to make a TurnKey Linux pump.io system... this way you can use virtualbox or vmware to run pump out of the box and play with it.

[18:59] <paroneayea> too bad npm is such a nightmare, I'd love to make a guix package

[18:59] <larjona> Nemno that would be great

[18:59] <Nemno> and the version of node, npm and libs will be all the same in a pump.io.iso

[18:59] --> guido has joined this channel.

[19:00] <strugee> so if we continue to use Zombie we need to use 2.x. I tried that and ran into some really weird bugs where some callback wasn't defined. and when I tried to debug it, I ran into suckiness with the 0.12 debugger

[19:00] <evanpro> So, unfortunately I have to get going

[19:00] <paroneayea> Nemno: that woudl be helpful, thanks!

[19:00] <strugee> also, for anyone not familiar: Zombie is the headless browser testing in use

[19:00] <evanpro> Can I ask that we meet next week at this same time?

[19:00] <strugee> evanpro: ok, thanks for stopping by

[19:00] <paroneayea> evanpro: I think that's a wise idea

[19:00] <evanpro> strugee: is there a better alternative?

[19:00] <paroneayea> why don't we roll over issues to next week

[19:00] <larjona> I'm available, I could chair next week

[19:00] <strugee> evanpro: dunno. I haven't looked into it a huge amount

[19:00] <evanpro> Zombie is pretty great to use, but it's got some really janky async

[19:00] <paroneayea> larjona: \o/

[19:00] <strugee> we could use PhantomJS

[19:01] <paroneayea> larjona: can you also put out announcements and etc then?

[19:01] <larjona> yes

[19:01] <evanpro> we could also just throw out the front-end testing

[19:01] <larjona> I'll handle all that

[19:01] <paroneayea> larjona: great

[19:01] <evanpro> It is not at all comprehensive

[19:01] <paroneayea> okay

[19:01] <evanpro> Or move it to a separate test suite

[19:01] <strugee> I'll take your word for it

[19:01] <paroneayea> isolating tests is a good idea

[19:01] <paroneayea> so this was a great meeting, *!

[19:01] <strugee> IIRC I ran the testsuite on 0.12 and there were ~5 that failed, which isn't that bad

[19:01] <paroneayea> thank you everyone for attending

[19:01] <strugee> most of those were browser tests

[19:02] <evanpro> That's not that bad

[19:02] <strugee> yeah

[19:02] <larjona> I'll cut the logs here, we can go on talking if you want

[19:02] <evanpro> It might be nice to try to get travis CI to work

[19:02] <larjona> =================== END LOGGING ==========================

Next meeting

Meeting 2015/10/15, 9AM PDT, #pump.io IRC channel at Freenode

Add a custom footer
Add a custom sidebar
Clone this wiki locally