15:00:30 #startmeeting hubs-devel 15:00:30 Meeting started Tue Jan 17 15:00:30 2017 UTC. The chair is sayan. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:30 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:30 The meeting name has been set to 'hubs-devel' 15:00:41 #topic Roll Call 15:00:46 .hello sayanchowdhury 15:00:47 sayan: sayanchowdhury 'Sayan Chowdhury' 15:00:57 .hello chawlanikhil24 15:00:58 chawlanikhil24_: chawlanikhil24 'Nikhil Chawla' 15:01:10 .hello devyani7 15:01:11 devyani7_: devyani7 'Devyani Kota' 15:01:14 .hello a2batic 15:01:14 a2batic: a2batic 'Kanika Murarka' 15:01:27 mizmo: jcline: abompard: meeting time 15:01:30 .hello jcline 15:01:31 jcline: jcline 'Jeremy Cline' 15:01:44 .hello duffy 15:01:45 mizmo: duffy 'Máirín Duffy' 15:02:13 #chair devyani7_ a2batic jcline mizmo 15:02:13 Current chairs: a2batic devyani7_ jcline mizmo sayan 15:02:16 .hello pfrields 15:02:17 stickster: pfrields 'Paul W. Frields' 15:02:24 #chair stickster 15:02:24 Current chairs: a2batic devyani7_ jcline mizmo sayan stickster 15:03:01 last week we had a couple of meetings mostly centered around IRC 15:03:25 *nod, seems like that is the critical piece to get in ordr so we can get a working hub out 15:03:25 .hello abompard 15:03:26 abompard: abompard 'Aurelien Bompard' 15:03:30 and fixing the things in the workflow of ircb, waartaa and fedora hubs integration 15:03:34 .hello wispfox 15:03:35 shillman: wispfox 'Suzanne Hillman' 15:03:45 #chair abompard shillman 15:03:45 Current chairs: a2batic abompard devyani7_ jcline mizmo sayan shillman stickster 15:03:58 #topic IRC Widget 15:04:39 jcline and me both wrote a writeup on what things were discussed 15:05:18 #link https://etherpad.gnome.org/p/waartaa 15:05:29 #link https://public.etherpad-mozilla.org/p/Hubs_IRC_planning 15:06:33 The plan is that we move this writeup to the IRC widget ticket so that it would be easier for someone coming over to the IRC widget to understand 15:07:00 *nod 15:07:01 .hello vivekanand1101 15:07:02 vivek_: vivekanand1101 'Vivek Anand' 15:07:10 #chair vivek_ 15:07:10 Current chairs: a2batic abompard devyani7_ jcline mizmo sayan shillman stickster vivek_ 15:08:05 Another plan is to break this into small tasks and add that to both hubs pagure trac and the one linked with to ircb 15:08:23 Something just occurred to me: do we want to let guests talk on the IRC channel, perhaps only for regional hubs, thereby making it easier for a visitor to know if they want to join it? 15:08:26 in the comments itself and make them off as complete when they are done 15:09:18 shillman: maybe let them view it if we do a unauthenticated view but talking probably not 15:10:18 k. 15:10:19 mizmo: also only people who are member of a particular hub can talk and activate the IRC widget? 15:10:38 sayan: no anybody visiting can do it, you dont have to be a member 15:11:08 sayan: eg if im on the ambassadors and i want to talk to design about getting a banner designed... i need to be able to go to their hub and talk to them without having to join as a member 15:12:15 mizmo: that means, if the person is authenticated, they can talk 15:12:54 sayan: if the person has a FAS acct and is logged into hubs, they can talk as long as they go thru the bootstrap process we've talked about (activating IRC widget, etc) 15:12:55 Hmm. So would the bouncer join the channel when they visit that hub and part when they leave? 15:13:28 id like ppl to be able to have backscroll, which is what i thought part of the point of the bouncer was 15:13:29 (that is, what is the expectation of chat history here) 15:14:51 if they login to the channel that should log for them 15:15:04 .hello chawlanikhil24 15:15:05 chawlanikhil24: chawlanikhil24 'Nikhil Chawla' 15:15:06 so when we talked about this feature early on some folks had privacy concerns about backscroll 15:15:23 Okay, so they'd go to a hub and activate the widget and then they'd stay in that channel until they deactivate the widget? 15:16:00 if we want to show them say 20 lines of backscroll when they log in, is that possible even tho they never logged in before? 15:16:08 apps like slack and riot do that 15:16:50 If we had the Hubs server logged into every channel registered that would be possible I suppose 15:16:53 mizmo: yes, that's possible if somebody is already there for whom the channel is logged 15:17:11 sayan: ok great 15:17:17 It might be better as a later feature rather than something we do initially 15:17:32 yup 15:17:43 are we going to have an uprising bc we're logging channels? 15:17:43 when do we purge logs? can we? 15:17:54 ircb does not do duplicated logs, it keeps logging until the last person logs out 15:18:16 Oh 15:19:06 mizmo: do we need to purge? 15:19:25 sayan: there are folks with privacy concerns about logs. 15:19:47 so we need to have some kind of policy about how long we retain them 15:20:50 but suppose I am using the service and I need the logs from the time I am in the channel 15:20:52 it can be years 15:22:08 Maybe that's not a use case we solve. If that's the kind of thing someone wants, we can recommend their own bouncer. 15:22:12 so that's going to be problematic for a lot of people 15:22:12 i think if you want to keep logs ad infiniteum, you're going to have to connect to ircb from an external logging client and save them yourself 15:22:12 if we're going to provide the kind of privacy we have users requesting 15:22:12 we could also have a no-log option 15:22:23 jcline: oh thats smart too 15:22:48 the only thing is that if high privacy requires setting a config option (whether it's plugging in another bouncer or w/e) is that ok? 15:22:56 i think it's important the default *just works* for the less technical folks 15:23:16 I think that sort of thing is something an experienced user would want anyway (they've been around years after all) and maybe isn't our target audience with this feature. 15:23:23 however one thing that came up in wispfox's research is folks from certain countries who are afraid of their govt 15:23:32 and may not realize logs of their convos are sitting on our server 15:23:55 so they may not be technical and may not realize, maybe we're putting them at risk 15:23:56 We could just have a scrollback setting for channels that's like... 500 lines or something 15:24:16 mizmo: Good point. mizmo++ 15:24:16 shillman: Karma for duffy changed to 11 (for the f25 release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:24:26 in that case ircb should have a feature to config the maximum logs to be stores 15:24:32 * stickster doesn't understand this privacy concern fully considering the communication is public 15:24:36 the thought meghan and i had when we designed the private irc feature a couple summer ago was that we could have a channel scrollback setting that's maybe 500 yeh or maybe 1000 lines 15:24:48 stickster: +1 15:24:51 but we also have to store logs for people's PMs they receive while logged out until they log back in 15:25:15 also if they get pinged in channelw hile not logged in 15:25:15 the idea we had for that was maybe 10-20 lines before and 10-20 lines after 15:25:41 stickster: right but irc isnt meant to be permanent like say a blog post or whatever and keeping years worth of logs forces it to be. it's way less formal than that. 15:26:16 stickster: theres a lot of scary things you can come up with doing analysis on years of chat logs. where was this person at this time on this day, etc 15:26:19 mizmo: I totally agree we don't want to store logs forever... a window of "last N messages" sounds fine, though. Is someone objecting to that? 15:26:45 stickster: i think we did ablog post back in the day about that idea and never had any pushback about it 15:26:56 i could do a fresh blog post about this conundrum and summarize this convo and see what people think 15:27:19 Well if we can't store *anything* then it may as well be one of those web clients that joins and parts when you leave the page and forget the bouncer entirely :) 15:27:21 mizmo: yes, that should be configurable, when we setup ircb in the fedora's server we configure to store last N messages 15:27:24 #link http://www.rtnpro.com/challenges-with-irc-log-storage/ 15:27:36 But then it's not very useful 15:27:58 sayan: +1, we can set a maximum and go with that. jcline, agreed, we need to have some backscroll to be useful. 15:28:27 sayan: can we store last N messages + context around pings and PMs that have not yet been received? 15:28:27 well 15:28:27 we want this out the door at some point 15:28:27 we could just say all or none, if you dont want it use a diff bouncer 15:28:35 but then ppl will argue their messages are in the logs even if they never log into hubs since they're communicating w people who are 15:28:38 mizmo: +! 15:28:48 +1 15:29:11 but right now lots of people log irc on their local machines anyway. i have years worth of logs 15:29:43 i would say make sure theres a setting but maybe for getting a feature stood up and running make it all or none 15:29:53 mizmo: "ppl will argue their messages are in the logs..." are you talking about PMs or channel msgs? 15:29:55 me too. that's why if people want to store logs then they can go ahead and setup their own bouncer 15:30:05 stickster: both 15:30:35 mizmo: channel msgs == not an issue to me, provided we don't store indefinitely (only last N msgs). These are public, there is no privacy protection to be had. 15:31:25 Our job is not to engineer additional privacy around a public channel, and not storing historical stuff past N msgs makes sure that it can't be abused further via our service 15:32:38 how about for private messages, if someone not using ircb pm's someone who is, it gives them a little notice that the user logs it? 15:32:40 As for private messages, we should probably have people confirm they understand we'll store a PM for them so they can access it later, and if they decide to get off hubs, we'll evaporate those 15:33:29 mizmo: like, " is not around, but the Hubs bouncer has recorded this message to deliver to them when they sign back in." 15:33:31 yeh that makes sense too stickster 15:33:39 stickster: exactly 15:34:06 sorry i ddidnt mean to create a worm hole here, i just remember there was a lot of pushback about logs even tho i think they are key to making this feature useful! 15:34:09 and we should probaly store a maximum of PMs too, so we don't have the problem of someone signing in once, and then getting spammed to the point we store a bunch of junk 15:34:11 Yeah, I like those combined. :) 15:34:40 mizmo: not a problem, good to understand the issues. all I'm saying is let's not undertake obligations we don't have :-) 15:34:58 okay to summarize: 15:35:09 - we log last N messages in channels (N TBD) 15:35:13 - we log PMs 15:35:37 - we notify users PMing an ircb user that their message is being logged on first message 15:35:58 - when a user leaves hubs, we erase all their PM logs 15:36:21 - we should have a max # of PMs too to avoid spamming users on first login in a long while 15:36:40 - public IRC channels are public, expectations of privacy should be limited 15:36:45 anything else I forgot? 15:37:10 - when users first log into a channel they should get some backscroll 15:37:25 sounds right to me 15:37:37 We should tell users that their PMs will be stored while they are offline, too. 15:37:41 I think that was in there. 15:39:06 So one thing I'm concerned about is there are no docs for ircb. Does its API (does it have an API?) give us everything we need here? 15:40:05 shillman: ah, +1 15:41:17 jcline: yes, that is possible. The features are not there though 15:42:33 sayan: Does ircb have an API? 15:42:50 stickster: yes, it has 15:42:54 cool 15:43:35 it would be nice to see docs at least in the code... at least in the API... do those exist somewhere? 15:44:06 stickster: nope, there are no docs yet 15:44:11 There's plenty of tools to generate nice HTML documentation for docblocks 15:44:19 as the plan was waartaa using the API 15:44:36 so waartaa communicated to ircb using the same API 15:46:28 Anything to be discussed from the etherpad? 15:47:23 - 15:48:09 sayan: who's writing code for the various pieces here? Is that all in the github issues at this point? 15:48:27 or is that waiting on everyone to say +1 to the plan here? 15:49:12 since last week was mostly planning and chalking out things. 15:50:11 Now that we had the plan we can go ahead with adding the issues that needs to be worked on 15:50:15 The flow in the EP makes sense to me 15:50:32 * stickster added shillman's point about storing channel msgs 15:50:54 so let write the issues that can be 15:51:03 - connecting ircb with fedora-hubs 15:51:32 - requesting the user for nick 15:52:20 ^^ this step would also include registering the user to ircn 15:52:30 s/ircn/irc 15:52:57 - update the FAS with the irc nick 15:53:42 - sending a request to ircb create the user and log the user in 15:54:05 ^^ this would be a API/websocket call 15:54:56 These are the issues I am planning as tasks in the etherpad too and check off once done. 15:55:16 And the issues are dependent on one another 15:56:03 so if somebody wants to help we can collaborate from the first issue itself 15:56:18 sayan: plan in the EP makes sense, I trust you don't mean tracking progress in the EP too? 15:56:48 stickster: nope, tracking would be in hubs issues 15:56:54 sayan: right on 15:57:16 EP is just for the draft of what we paste in the issues 15:57:33 Should be create different tasks I listed above? 15:57:38 s/tasks/issues/ 15:59:27 It might be worth comparing them to the stories I wrote 16:00:27 Okay, so should we go ahead with an issue for each user story? 16:01:09 jcline: ^^ 16:01:15 * stickster has to depart for another meeting 16:01:28 I think so. How I've normally done it is start with something like what we have and then flesh out the details in the comments and continue to update the initial issue 16:01:59 jcline: yes, that's something I was also thinking 16:02:42 we do mention the issues created for stories in the intial issue 16:03:40 I'm not sure I understand what you mean by that 16:05:23 jcline: so my idea was that the write that you have in the EP would go in to this issue https://pagure.io/fedora-hubs/issue/2 16:07:01 Okay, yeah. What I had in mind was the top section of the EP would go there and then for each section underneath that describes a piece of functionality goes in its own issue that blocks issue #2 16:07:31 Then you can see all the issues that block the overall story and set blocking relationships between those sub-tasks as well 16:07:45 jcline: yep, right 16:07:52 Cool 16:08:13 I'm happy to do that, as well 16:08:15 jcline: would you create that in pagure? 16:08:27 Yup! 16:09:19 #action jcline to setup overall story for IRC widget along with the sub tasks 16:10:14 for this week let me work on the configuration needed for API, docs and setting the hubs and ircb connection 16:10:36 maybe write setup blog so that people can start helping 16:10:52 sayan++ 16:10:52 devyani: Karma for sayanchowdhury changed to 7 (for the f25 release cycle): https://badges.fedoraproject.org/tags/cookie/any 16:11:15 sayan++ 16:11:15 vivek_: Karma for sayanchowdhury changed to 8 (for the f25 release cycle): https://badges.fedoraproject.org/tags/cookie/any 16:11:22 #action sayan to work on the configuration needed for API, docs and setting the hubs and ircb connection 16:11:41 we are over-time 16:11:43 Sounds good 16:11:53 #topic Open Floor 16:12:03 Anything else to discuss? 16:12:44 jcline: do add the logging points we discussed too 16:13:04 Will do 16:13:14 backend script of release widget is ready, needs integration with hubs + saptaks has made the front end responsive again 16:13:14 ending the meeting 16:13:16 Sayan: can you setup any time this week. The bookmarks do not populate 16:13:31 devyani: ok, I will do 16:13:46 sayan, FYI I've recently set up a lot of sphinx docs projects so all the fiddly settings are still fresh in my mind 16:13:46 vivek_: cool, let's discuss this tomorrow 16:13:50 Thankyou :) 16:13:50 ok 16:14:20 jcline: will ping you if I need help 16:14:48 I'll setup ircb.rtd.org 16:15:26 #endmeeting