greptilian logo

IRC log for #openknot, 2015-07-17

Open Knot Communications Platform - https://github.com/openknot

| Channels | #openknot index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

All times shown according to UTC.

Time S Nick Message
00:03 dotplus your point?
00:04 pdurbin oh, just thinking about usability. I agree it might be nice if account creation generates a keypair if the system requires it.
00:06 pdurbin oh, I added "Open Knot Communications Platform - https://github.com/openknot " to the top and bottom of http://irclog.greptilian.com/openknot/today but I can change it to whatever people want.
00:36 dotplus sounds good to me, at least for now.
00:37 dotplus I remember recommending dmmt the first time around. But nowadays I'm rather far away from webdev/design
00:37 pdurbin oh so you've read it. I enjoyed it
01:49 dotplus it reminded me of Donald Norman really.
01:50 dotplus iirc
05:24 philbot joined #openknot
05:24 Topic for #openknot is now https://github.com/openknot | this channel is logged to http://irclog.greptilian.com/openknot/today
12:49 pdurbin thinking about IRC servers sending you recenty history the way XMPP (Openfire at least) can when you reconnect: https://gitter.im/gitterHQ/gitter?at=55a8f597f5bacb4732b057f5
13:11 dotplus add a suggestion into the functionality section?
13:12 pdurbin I guess I'm just wondering if existing IRC servers do this.
13:12 pdurbin not that I have any plans to run an IRC server. I'm quite content with freenode
13:13 dotplus never heard of that with irc, but my horizons w/IRC are rather narrow
13:15 dotplus looking at that page made me think about something. why do we have editors that support syntax highlighting?
13:19 dotplus for me, it's to help my puny mind scan the page more efficiently/effectuvely (to better grok the content and to decrease the time/effort it takes to do so)
13:20 dotplus how does syntax highlighting achieve these gains in efficiency/efficacy?
13:26 pdurbin yeah, can grok better
13:28 dotplus familiarity makes it an affordance. if my brain gets used to seeing the various syntactical components of my high-use programming/markup languages, it becomes a perceptual affordance (as used in POET/D. Norman).
13:33 pdurbin sure does
13:33 dotplus One excellent example of this was when much of my daily effort was Puppet (which, for the unfamiliar, is in a ruby-like DSL with some "real" ruby in places). I was using emacs as my primary editor with highlighting for puppet and ruby. I decided to experiment with vim, to give it a proper go (at the time I only had very basic vi/m skill) - the syntax highlighting was different such that it made such a difference to my ability to read puppet ...
13:33 dotplus ... code (that I had written as my major then current project, not someone else or ages previously) that I stayed with emacs as my editor for puppet and just moved to vim for other things.
13:35 dotplus the efficiency gained by the perceptual affordance of that particular style of highlighting and my habituation thereto was so high that it was worth the cognitive burden of 2 parallel editors.
13:37 dotplus why do I bring this up in #openknot? because I think this is a major point and purpose/goal of openknot... that it will allow people to gain the efficiency benefit of the perceptual affordances resulting from consistency of presentation.
13:40 dotplus there are several distinct styles/categories of communication from the user perspective (a/sync is the major, but also work/private, etc. ) and presenting consistently within a category, but distinctly across categories will be valuable. And the presentation style should be completely orthogonal to the transport.
13:41 * sivoais nods
13:41 sivoais I think the place to start is storing messages. Figure out the data model first. Then map the model to each transport.
13:42 dotplus which brings me back to the beginning and your gitter.im link. It was basically the same category of conversation as here in IRC, but since my irssi client and their webpage were *so vastly different*, I could actually feel the extra cognitive expense in parsing their page.
13:43 sivoais When I wrote my Facebook to NNTP portal, I found out that some of the Facebook API's metadata didn't map cleanly to NNTP.
13:44 sivoais For my first attempt, I threw away the extra data, but if I had designed my data model to be more general, I could have mapped it to more than just NNTP.
13:44 sivoais got to go, but I'll pop back here later
13:45 dotplus sivoais: yes, we need to decide what are the components of a message/principal/channel/server/service, what metadata do they each have?
13:46 dotplus and come up with a comprehensive data model for a minimal feature set.
14:20 sivoais one example is Likes and Favourites. NNTP clients can't use that in a portable way. I was thinking I could write a script for slrn specifically. ..
14:21 sivoais and handle it out of band
15:06 dotplus oh hipchat, I hate your excessive use of emoji, lack of readline support and awful regex support
15:53 pdurbin people used to rave about hipchat
15:59 dotplus plenty still do
16:00 dotplus Are you beginning to suspect that my desires about how I want things to work are not exactly typical?
16:32 bear IMO the data model is really simple for message storage
16:33 bear source id, source transport, message, target id, timestamp sent, timestamp received
16:33 bear everything else is additional data against the message id (oops - add message id to above)
16:34 bear because anything else is needed only for transport (and that data should be only stored in a log)
16:34 bear or for client side markup for presentation
16:44 sivoais and target id can be unicast, multicast, or broadcast ?
17:06 bear target id IMO is always and endpoint - and that endpoint can be uni, multi or broad
17:06 bear bear@knot.bear.im/irc/openknot
17:07 bear for example
17:23 dotplus and any metadata about thread/channel should be encoded in the sourceid/targetid?
18:01 bear that is my thought
18:02 bear but I have an xmpp bias and that's how it's done
18:02 bear unless all the parts use the same identity and then it's just routing
18:02 bear bear@bear.im would be the target id
18:02 bear and then discoverly at https://bear.im would show irc, web, xmpp, .... endpoints
18:38 pdurbin the use of email addresses as identifiers reminds me of webfinger: https://tools.ietf.org/html/rfc7033
19:11 bear it's not just an email address
19:11 bear that is also a XMPP JID and also the identity that IndieWeb folks use
19:55 pdurbin sure. the problem is people might spam you :)
20:11 bear yes, spam and other nuisances is something that will need to be worked out
20:15 sivoais haha, I'm trying to imagine reading mailing list e-mails inside of Twitter
20:17 dotplus oO(just because you can, does not mean that you should)
20:36 bear in my internal crazy vision - twitter is a place to publish but not to consume - I would read the incoming twitter items in my client using whatever view I was working with
20:36 bear irc channel for realtime events, web summary built from different views/filters, and so on
20:37 dotplus that's not crazy. I agree with it.
20:37 dotplus :)
20:41 bear :)
20:43 bear in the IndieWeb parlance we would POSSE (Publish Own Site, Syndicate Elsewhere)

| Channels | #openknot index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

Open Knot Communications Platform - https://github.com/openknot