| Time |
S |
Nick |
Message |
| 13:01 |
|
pdurbin |
interesting: "Whilst GitHub have improved the granularity of their scopes, there are still a few areas where we have to ask for more than we really require" https://gitter.zendesk.com/hc/en-us/articles/200176672 |
| 13:14 |
|
dotplus |
I do not agree with the opensourcedesign people. A wireframe is definitely not the first step here. A major part of the concept is that the system is client/frontend *independent*. |
| 13:15 |
|
dotplus |
I could imagine that example/prototype clients could help us think about the design of the service/system and the protocol, if the prototypes are sufficiently divergent |
| 13:19 |
|
pdurbin |
it's good to think of both the user experience and the back end implementation |
| 13:20 |
|
dotplus |
what do you (or people in general) mean by a mobile experience (I basically don't have mobile experience; I have a smartphone on which the only smarts I use a web browser, voip client, instrument tuner & vlc, so I'm vastly atypical)? does "mobile experience" just mean UX for little screens/touch/few buttons? |
| 13:24 |
|
dotplus |
right, I think UX design is important too. But I think we need to clarify the vision of what we're trying to achieve (both the longterm and the mvp) before we start to think about what it looks like. Yes, we should think about what the clients (can/should) *do*, but I think it's premature to concentrate on appearance until we've gotten a lot clearer about what it does |
| 13:25 |
|
pdurbin |
at the end of the day you're creating an experience |
| 13:26 |
|
dotplus |
This is a form/function debate. And the outcome in my mind is usually the same: something functional can be beautified, but it's much harder to bring high function to something beautiful (but useless) |
| 13:27 |
|
pdurbin |
I appreciate both perspectives. :) |
| 13:27 |
|
dotplus |
which is why you're (always?) the diplomat bringing folks together:) |
| 13:27 |
|
pdurbin |
heh |
| 13:28 |
|
dotplus |
a valuable function in its own right |
| 13:28 |
|
pdurbin |
for anyone catching up, we're talking about https://botbot.me/freenode/opensourcedesign/msg/44306421/ |
| 13:29 |
|
dotplus |
I think perhaps I misunderstood. Is the codecraft ML intended as the project list for this system? |
| 13:29 |
|
pdurbin |
nope |
| 13:29 |
|
pdurbin |
please see "about codecraft" http://or8.net/mailman/listinfo/codecraft |
| 13:30 |
|
dotplus |
yeah, I did. that was why I asked:) |
| 13:30 |
|
pdurbin |
basically, Michael and I send emails to each other. stuff like this: https://gist.github.com/pdurbin/908964e69c5c0e667f69 ... and I think he's thinking these should go to a list |
| 13:31 |
|
pdurbin |
not to speak for him |
| 13:31 |
|
pdurbin |
I hope he explains in an email to the list :) |
| 13:58 |
|
pdurbin |
anyway, great guy, we gave a talk together: http://iqss.github.io/javaone2014-bof5619 |
| 14:44 |
|
dotplus |
prologic: re: trying to cope with the noise. Yes, that's very important, we certainly won't want to use the system/service/community if it doesn't afford us functionality to help cope with badcomms like spam and too much good comms (information overload). |
| 14:47 |
|
dotplus |
But again, I think we need to first focus on enabling communication rather than preventing it. Definitely we should build filtering (both positive such as to enable finding what you want and negative such as antispam) functionality; definitely the deisgn docs should include mention of it, but I think it's premature to work on that until we've gotten some details about what exactly is a message, what is a thread, etc. |
| 15:31 |
|
bear |
an important goal/task/concept to keep in mind (IMO) is to not add a feature/design until you need it - in the case of filtering why even think about how it could be designed/spec'd until the other parts of the system are flowing |
| 15:33 |
|
bear |
short version of ^^ -- implement, increment around user experience to avoid architecture astronauts |
| 15:37 |
|
|
tumdedum joined #sourcefu |
| 15:37 |
|
|
bear- joined #sourcefu |
| 15:37 |
|
|
westmaas joined #sourcefu |
| 15:49 |
|
pdurbin |
bear: exactly. MVP |
| 15:51 |
|
bear |
yep - it's sooo easy to slide down the path of protocol design (because that part is kinda fun for follks) |
| 16:05 |
|
dotplus |
I'm not exactly what you mean by "architecture astronauts", but I'm going to guess you are referring to people who only think in a top-down, big-picture way? |
| 16:09 |
|
dotplus |
If so, I'm going to be slightly contrarian and say that the ideal includes both sides - both the hare, the bottom-up, 'build something that gets used' type and the tortoise. |
| 16:47 |
|
bear |
yep, that phrase is for people who think only in protocol design and never (hardly ever) implement the design |
| 16:47 |
|
bear |
so they tend to build lofty spires that look beautiful from space |
| 16:48 |
|
bear |
so yea, as long as it's always a dance/circle between design and implementation -- +1 |
| 16:50 |
|
dotplus |
yep, definitely to be avoided. My opinion is that you need both approaches. If you only have the bottom up, you end up with something that (at best) meets the immediate needs of the builder but is narrowmindedly focussed on just that and difficult to broaden. |
| 16:53 |
|
pdurbin |
there's too much agreement in here ;) |
| 16:53 |
|
dotplus |
a *small* amount of forethought to clarify what we're trying to achieve and ensure that we're all trying to achieve a (set of) common goal(s) followed by detailed specification and implementation of MVP(s) should avoid the worst of those problems. |
| 16:53 |
|
dotplus |
no there's not |
| 16:54 |
|
bear |
it's the "detailed spec" where I tend to disagree the most |
| 16:54 |
|
bear |
the spec needs to cover a known UX story and that is all |
| 16:54 |
|
bear |
and then you implement, find out the mistakes or edge-cases, adjust the spec and then iterate |
| 16:56 |
|
dotplus |
I don't mean detailed in the sense of comprehensively covering everything that is to be implemented. I mean detailed in the sense of *preceisely* covering some minimal functionality. |
| 17:33 |
|
bear |
ah - yea, sorry - those phrases I feel are trigger words for my brain when dealing with devs |
| 17:36 |
|
dotplus |
yep, I have been known to have that issue in my professional life, perhaps I need to work on my phrasing:) |
| 17:37 |
|
dotplus |
I forget, are you the #matrix and/or xmpp person who hangs out here? |
| 17:38 |
|
bear |
i'm very much an xmpp person |
| 17:38 |
|
bear |
(have served on the xsf board and our company has working for them quite a few xmpp folk) |
| 17:39 |
|
dotplus |
right. I knew there was someone like that here; I'm sure that experience will prove useful. could remember whether it was you or bene. I should read >2 chars of the nick. |
| 17:41 |
|
* pdurbin |
is forever trying to invoke semiosis rather than searchbot |
| 17:58 |
|
bear |
:) |
| 17:58 |
|
bear |
I'm hoping to be able to show how xmpp could work as the backend for a lot of this - especially with the now-web-friendly stanza.io library |
| 17:59 |
|
dotplus |
does xmpp say anything about message storage? |
| 17:59 |
|
bear |
yep |
| 17:59 |
|
bear |
offline and archive |
| 17:59 |
|
bear |
offline "stock" for anyone who is not active but have messages pending |
| 17:59 |
|
bear |
archive allows for storage after delivery |
| 18:00 |
|
dotplus |
interesting. |
| 18:01 |
|
bear |
xmpp also allows for push notifications - one of our devs is working on making that work for desktop and mobile (ios and android) |
| 18:02 |
|
dotplus |
"our"? |
| 18:02 |
|
bear |
oh - sorry - I work for &yet (andyet.com) |
| 18:03 |
|
bear |
and we use a lot of xmpp and are the caretakers of stanza.io and otalk.org |
| 19:15 |
|
pdurbin |
dotplus: https://botbot.me/freenode/opensourcedesign/msg/44413076/ |
| 19:27 |
|
dotplus |
pdurbin: oops, apparently I upset someone. I wasn't saying he's an idiot for suggesting wireframing, just that I don't see that as the most effective next step for this particular project. But he's right, I'm sure more context would have helped me see his position. I still think that, at least in my vision, this starts out as a backend project. If nothing else, because there are already existing frontends, the various client (libraries) for ... |
| 19:27 |
|
dotplus |
... IRC/XMPP/NNTP/zephyr/SMTP/etc. which already cover at least part of the functionality. (but, yes, none of which individually supports all of the functionality I have in mind) |
| 20:55 |
|
prologic |
dotplus, indeed |
| 21:00 |
|
dotplus |
In the interests of getting _something_ going: https://github.com/dhutty/knot |
| 21:00 |
|
bear |
the design folks could help discover/document the UX for the existing user stories tho |
| 21:00 |
|
dotplus |
sure, that would be lovely |
| 21:01 |
|
bear |
I would love to try and get Prosody (an XMPP server) to be one of the initial test beds for this |
| 21:01 |
|
dotplus |
after all, I wouldn't want to be considered just a bikeshedder:) |
| 21:01 |
|
* bear |
chuckles |
| 21:06 |
|
dotplus |
I don't have enough experience with more than the basics of xmpp to know whether it would fit the needs. let's take a little while to think about what we want first. it's quite possible that a reasonable approach to this is a few separate but integrated services: a basic messaging service, a threader/classfier, storage, filtering service, search/browse, perhaps others. |
| 21:06 |
|
dotplus |
idp |
| 21:07 |
|
dotplus |
and the more of those we can reuse from elsewhere, the better (if it's not more work to bend them to our will than to start from scratch) |
| 21:07 |
|
bear |
right - I'm thinking the same thing but with my xmpp knowledge i'm hoping it could be the central identity/routing hub that other services could be attached to |
| 21:08 |
|
bear |
but as some of the IndieWeb folks would say - that is implementation talk, let's get some UX stories going and then see what fits |
| 21:08 |
|
dotplus |
at the moment, I don't have an opinion on that. |
| 21:09 |
|
bear |
I was reading your punch list for knot and feel that most of them are handled by xmpp with a web front end |
| 21:09 |
|
bear |
so that's why I mentioned it |
| 21:10 |
|
dotplus |
yeah, I'd be glad to hear more about how it might work. |
| 21:11 |
|
bear |
xmpp has federation built in as well as allowing anonymous and authenticated auth |
| 21:11 |
|
bear |
the identity (aka the JID or Jabber ID) also has a concept of a roster |
| 21:11 |
|
dotplus |
yup, I'm aware of that. are there existing projects for storing xmpp with reasonable search? how about the filtering side of things? |
| 21:11 |
|
bear |
so you can group folks and also store meta data like IRC, email, etc |
| 21:12 |
|
bear |
the xmpp folks feel that filtering and search are client side events that are enabled thru pubsub or notifications |
| 21:12 |
|
dotplus |
that==federation and auth/auth. roster is new to me. |
| 21:13 |
|
bear |
so the filter and search is something I would have to get a test implementation running to show how it could work |
| 21:13 |
|
dotplus |
yeah, I'm not sure how I feel about that. I think I want server-side filtering as well as client side |
| 21:13 |
|
bear |
I agree - using an xmpp component the server side would be able to see all messages to the server |
| 21:13 |
|
dotplus |
for example, I know I don't want the whole of usenet sent to my client... |
| 21:13 |
|
bear |
so rules filter and search would be doable, would just need to work out the command/rpc calls to the component |
| 21:14 |
|
bear |
yea, I see that as a server side gateway which knows how to insert into the message store - so each usenet becomes a service JID |
| 21:14 |
|
bear |
usenet:topic.server.foo bear.im |
| 21:14 |
|
bear |
or some such |
| 21:15 |
|
dotplus |
"each usenet" you mean each "newsgroup"? |
| 21:15 |
|
bear |
yea, i'm doing a bit of hand waving |
| 21:16 |
|
bear |
the gateway would be for usenet and then each newsgroup within it would be a jid against that gateway |
| 21:16 |
|
bear |
so foobarusenet.bear.im |
| 21:16 |
|
dotplus |
which shows we need to settle on some terminology:) newsgroup/chatroom/channel/list seem to be approximately the same (from nntp/xmpp/irc/mailinglists respectively) |
| 21:16 |
|
bear |
oh yea, the terms for each thing and their mapping is going to be crucial |
| 21:17 |
|
bear |
I started doing this 15 yrs ago and never finished for a lot of small/large reasons -- I'm very excited to be thinking about this again |
| 21:18 |
|
dotplus |
great! |
| 21:19 |
|
dotplus |
well, please write down your ideas, suggestions, experiments, stories that you think of, etc. either as issues or PRs for that knot repo and we'll see where we go, |
| 21:19 |
|
bear |
k |
| 21:19 |
|
dotplus |
of course, I'm not tied to that:) |
| 21:20 |
|
dotplus |
there's one to mess with non-native english speakers |
| 21:20 |
|
bear |
I love the name; the name I was using back then was "duct" so i'm liking yours a lot more than my old one |
| 21:22 |
|
dotplus |
my thinking is based on emphasising the thread/weave aspect. and it lends itself to a nice simple logo |
| 21:23 |
|
dotplus |
https://en.wikipedia.org/wiki/Triquetra |
| 21:24 |
|
dotplus |
prologic: I'd love to hear from you https://github.com/dhutty/knot |
| 21:24 |
|
dotplus |
but for now, I gotta go |
| 21:31 |
|
pdurbin |
dotplus: excellent write up |
| 22:16 |
|
pdurbin |
sivoais: did you see it? |
| 22:18 |
|
sivoais |
I did read over it |
| 22:18 |
|
pdurbin |
I don't know what the hell zephyr is. And no mention of gopher, prologic :) |
| 22:19 |
|
sivoais |
isn't zephyr the thing used at MIT? |
| 22:19 |
|
sivoais |
it's an IM protocol |
| 22:19 |
|
sivoais |
This might be worth looking at <https://github.com/w3c-social/Social-APIs-Brainstorming> |
| 22:19 |
|
sivoais |
I believe the people in #microformats are working on the above or related ideas |
| 22:20 |
|
sivoais |
yeah, from MIT <https://en.wikipedia.org/wiki/Zephyr_(protocol)> |
| 22:22 |
|
bear |
sivoais - I am an active lurker in #indiewebcamp and I interact with a lot of the microformats crew who are active in the w3c |
| 22:22 |
|
bear |
(saying the above so that you all know my bias is definintely towards indieweb and microformats) |
| 22:22 |
|
sivoais |
yeah, #indiewebcamp too... I lurk there too |
| 22:25 |
|
pdurbin |
dotplus: I do like how you want to delight users. So do I. |
| 22:26 |
|
sivoais |
:-D |
| 22:28 |
|
pdurbin |
I wonder if that's from somewhere. Delighting users. |
| 22:28 |
|
pdurbin |
sound kind of agile |
| 22:30 |
|
sivoais |
MVP vs. MDP: <http://www.startupblender.com/minimum-viable-product-vs-minimum-delightful-product/> |
| 22:30 |
|
sivoais |
:-) |
| 22:32 |
|
bear |
oh - I like that |
| 22:32 |
|
* bear |
steals |
| 22:33 |
|
pdurbin |
oh, wait. the agile manifesto is apparently super short |
| 22:33 |
|
pdurbin |
https://en.wikipedia.org/wiki/Agile_software_development#The_Agile_Manifesto |
| 22:46 |
|
prologic |
morn'n all |
| 22:47 |
|
prologic |
dotplus: Oh? is this the name we're going with? |
| 22:47 |
|
prologic |
knot? |
| 22:51 |
|
bear |
i'm feeling a good vibe towards knot |
| 22:51 |
|
prologic |
yeah it's not bad tbh :) |
| 22:51 |
|
prologic |
dotplus: I submitted a PR :) |
| 23:03 |
|
bear |
you had to go and add semantic to the text ;) |
| 23:04 |
|
bear |
my hope is that a schema won't be needed as the content marked up will *be* the schema |
| 23:04 |
|
bear |
ala microformat |
| 23:05 |
|
bear |
and any schema required will be dictated as part of the transport |
| 23:05 |
|
bear |
hmm, I should add the above as comments to the PR |
| 23:21 |
|
prologic |
haha |
| 23:21 |
|
prologic |
yeah see |
| 23:21 |
|
prologic |
this is the very thing we're trying to solve |
| 23:21 |
|
prologic |
we're communicatin in both places |
| 23:21 |
|
prologic |
duplicating! |
| 23:21 |
|
prologic |
haha |
| 23:22 |
|
pdurbin |
:) |
| 23:24 |
|
pdurbin |
good luck |
| 23:24 |
|
pdurbin |
turns out you can write a letter and then bump into the same person on the street |
| 23:26 |
|
* pdurbin |
gets the kids off his lawn |
| 23:28 |
|
pdurbin |
prologic: at least dotplus did your job for you. you had volunteered to write something :) |
| 23:28 |
|
prologic |
no no |
| 23:28 |
|
prologic |
he hasn't (yet) :P |
| 23:28 |
|
prologic |
this is a good start though |
| 23:29 |
|
prologic |
it contains a concise list of our ideas |
| 23:29 |
|
bear |
+1 |
| 23:29 |
|
prologic |
A design is yet to be done :) |
| 23:29 |
|
prologic |
but also not trivial |
| 23:29 |
|
prologic |
there are many challenges to solve |
| 23:29 |
|
prologic |
interoperability, scalability |
| 23:29 |
|
prologic |
storage |
| 23:29 |
|
bear |
getting same-page-ified for terms and core goals is exactly what is needed for this IMO |
| 23:29 |
|
pdurbin |
did you see all the chatter about UX/UI challenges? |
| 23:38 |
|
pdurbin |
probably good to start with user stories |
| 23:41 |
|
dotplus |
zephyr was, to my knowledge, the original IM protocol. long before ICQ. there, bet you haven't thought of *that* one in a long time. I came across zephyr when I worked at cmu.edu. |
| 23:42 |
|
pdurbin |
huh. ok |
| 23:42 |
|
pdurbin |
dotplus: good on you for starting a repo. that's the spirit! |
| 23:43 |
|
bear |
yea, zephyr pre-dated a lot of things |
| 23:43 |
|
pdurbin |
even `talk`?!? |
| 23:43 |
|
dotplus |
zephyr was (is) multi-host |
| 23:44 |
|
dotplus |
but no, talk, is ancient. I think it was multics |
| 23:45 |
|
pdurbin |
I used it on a VAX. |
| 23:45 |
|
bear |
talk is original *nix IIRC |
| 23:46 |
|
bear |
it was even on later PDP's |
| 23:46 |
|
bear |
s/is/predated/ |
| 23:47 |
|
dotplus |
not going to wave my cane. I'm a latecomer. But before I got into this game, I had several other "careers" |
| 23:48 |
|
prologic |
I think we should hold off on any user stories per se |
| 23:48 |
|
prologic |
until we have nutted down how we envisage it'll work |
| 23:48 |
|
prologic |
a design is very important to succeed ihmo |
| 23:48 |
|
dotplus |
I like the idea of backwards and forwards compatible, I'm not sure we have the phrasing right yet. |
| 23:48 |
|
prologic |
but let's finish/polish off this ideas dodcument first |
| 23:48 |
|
prologic |
yeah |
| 23:49 |
|
prologic |
well that's the kind of thing JSON Hyper Schema promotes |
| 23:49 |
|
bear |
my thought was that we start with a set of small but core UX stories |
| 23:49 |
|
prologic |
is an API that's self documenting, backwards/forward compatible |
| 23:49 |
|
* bear |
waves his cane a lot also ;) |
| 23:49 |
|
prologic |
so we can change/mutate it at our will |
| 23:49 |
|
prologic |
and clients don't have to change |
| 23:49 |
|
prologic |
lol |
| 23:49 |
|
bear |
I'm in agreement if the json structure is *very* minimal |
| 23:49 |
|
prologic |
well yeah okay |
| 23:49 |
|
dotplus |
"later versions (of the API/format) will support all prior versions, being a superset of the functionality"? |
| 23:49 |
|
prologic |
we can at least jot down what the user experience *should* be like as such |
| 23:49 |
|
bear |
and most of the schema is inside/part-of the content |
| 23:50 |
|
prologic |
*nods* |
| 23:50 |
|
prologic |
that's the general idea yeah |
| 23:50 |
|
prologic |
I've myself built such an API before |
| 23:50 |
|
prologic |
and it works really really well |
| 23:51 |
|
bear |
yes, all of my past successful api's have followed that pattern |
| 23:51 |
|
bear |
the ones that I didn't follow, failed in spectacular fashion |
| 23:51 |
|
dotplus |
perhaps you could add links to references and/or examples about the hyper schema? |
| 23:53 |
|
dotplus |
^ prologic |
| 23:54 |
|
dotplus |
I mean, add them into the PR not just the commentary, |
| 23:56 |
|
prologic |
yeah sure |
| 23:56 |
|
prologic |
I will :) |
| 23:56 |
|
prologic |
prod me in ~8hrs tonight when I'm home :) |
