Text extraction. See Typescript Archive <style>#typescript-2024-08-25 .markdown p:not(:has(em)) { margin-top: 0px; margin-bottom: 0px; } #typescript-2024-08-25 .markdown p:has(em) { margin-bottom: 0px; } </style>
17:28:49
*17:28:49 From Robert Best* Have you discussed the issue Thompson was having with scripts on his login to view site? Something about the frame plug-in maybe needing to pass something like credentials along in some way with how it frames content since restricted sites pretty much always need you authenticated to work.. maybe I'm missing part of what the issue was with him having the solo plugin work with aspect assets etc.
17:33:22
*17:33:22 From Jeff Miller* nodding in "code maintained by multiple people" (should have a familiar pattern)
*17:35:14 From Jeff Miller* oh right, Kill It With Fire (or don't)
*17:35:53 From Brian* +1 to migrating, but refactoring agressively.
*17:35:54 From Jeff Miller* I met the author at Strange Loop, before-ish of her modernization experience. (before the book, certainly)
The experiments are a question to the protocol, and valuable as such.
*17:36:15 From Brian* The poop rule: If there was poop on the item, would you clean it up or throw it away...
*17:36:56 From Jeff Miller* a conversational effort for the CoffeeScript to Javascript conversion (yes to Eric's point)
"Like a Pivotal Labs programmer" on a shared project
*17:39:08 From Jeff Miller* "platform drift" - follow the platform or go extinct (Ward's term) as contrasted with technical debt: deferred work.
*17:40:18 From Jeff Miller* aha, "wiki" as a global object most places (to ESLint's complaints), limits to using code linting when order of init is important.
Ward points out that "wiki" is an affordance designed for the plug-ins rather than the core.
(a thing to discuss and think about)
absorbed plug-ins?
organelles?
*17:41:46 From Jeff Miller* (while we're talking wiki updates, I suppose I should update http://pixiereport.com)
*17:42:49 From Jeff Miller* which on Chrome, I have to phrase as http://pixiereport.com:80/ to prevent the upgrade to a different site entirely!
*17:45:17 From Jeff Miller* http://plugins.dojo.fed.wiki:80/ as a searchable wiki for plugins (whereas the "about" pages aren't typically searchable as pages)
17:50:44
*17:50:44 From Jeff Miller* Discussion of the CoffeeScript conversion as a collaborative project which people might find ways to participate in, according to preference and interest.
*17:51:06 From jan dittrich (er/he|they)* Reacted to "Discussion of the Co..." with 🙏🏻
*17:51:31 From Jeff Miller* the decaffeination vision manifesto? (Jeff, to Brian's question about the project's premises)
*17:51:48 From jan dittrich (er/he|they)* Reacted to "the decaffeination v..." with 😆
*17:52:31 From Jeff Miller* Wiki as website? (CSS selectors, DOM manipulation) vs. Wiki as platform (more attention to portability and protocols)
Brian appreciates the Deno implementation for speed (over Node), so that wiki-as-platform has value; potentially generative value.
*17:54:01 From Jeff Miller* Limitations of various platforms (e.g. GitHub Pages for static hosting, and aliasing of page-name vs. page-name.json)
Hosting within an institutional domain (in a subdomain) - needs a different client/server protocol and conventions from the usual Federated Wiki.
*17:56:26 From Jeff Miller* Eric recalls static wiki hosting challenges including: URL translation (page-file.json) and rehosting in a static file path structure from the paths as resolved in wiki; Creating an .html page which knows how to load the .json (another part of URL path protocol to filesystem paths)
A clever hack for Eric's usage of URLs for page lineups; it looks like a path of view/page-slug/view/page-slug-2/
*17:57:23 From Peter* like the old Smalltalk 'doesNotUnderstand' tricks
*17:57:26 From Jeff Miller* The clever hack is using the 404 page to construct the "not found" mechanism
Yes, yes, it's doesNotUnderstand as a dispatcher!
*17:57:49 From Paul Rodwell* needs to be some lookup that maps “Fred’s wiki” to have a prefix “university.org/path/to/freds-wiki”
*17:58:12 From Jeff Miller* spirits called from the vasty deep!
*17:58:58 From Peter* lineup as query parms rather than embedded in URI
*17:59:25 From Jeff Miller* Eric's attempted refinement to avoid the magic 404 trick in the filesystem / file-path / URL-path translation raised another problem for static sites.
*17:59:50 From Paul Rodwell* this is much the same problem as many other protocols where we would want a readable name to refer to a wiki, rather than say some crypto hash as a name
*17:59:53 From Jeff Miller* The wiki-client needs to know the content root to be hosted at a point other than the root of a domain.
(I am thinking of path names as an API fairly often since I launched PixieReport, and want to avoid creating mess and breakage)
*18:00:58 From Jeff Miller* GitHub pages - too cheap to meter! 🙂
*18:02:19 From Jeff Miller* "If I can use the 404 trick on GitHub pages for static site hosting, I can use the same trick for the Apache webserver outside of GitHub" -- then publish-to-static can be relatively easy to set up and maintain.
"edit locally, push to public" as a known workflow where a personal wiki can act like a static site generator workflow, where the hosting is low-friction in the same sense as SSGs.
*18:03:47 From Jeff Miller* Brian envisions different clients which agree on a protocol but have very different client presentation visions.
(Jeff imagines: federated page spaces for the millions?)
what Wordpress has been for blogs?
*18:05:10 From Jeff Miller* "a client with a static publishing workflow and a static hosting workflow, the active behavior could be served from frames" - Eric reflects
"There might be faster paths to hosting the client statically." - what Eric hears in Brian's reflections.
18:08:17
*18:08:17 From Brian* To the extent that the server can be a key-value store, I think that preserves the most [cheap] options...and could play nice with local storage concepts
*18:08:33 From Jeff Miller* Andrew reflects on a similar pattern with a static site backed by an update workflow (statically hosted, updates go to a separate back-end process, then pushed behind the scenes).
*18:09:11 From Brian* Plugins as a service? :/
*18:09:24 From Jeff Miller* Andrew muses on a plugin protocol which returns repurposable HTML.
"the result can be used in lots of different places"
Eric reflects on this sort of approach -- repurposable HTML -- as one that would allow richer on-disk static pages.
*18:11:01 From jan dittrich (er/he|they)* the https://htmx.org/ school of frontend?
*18:11:04 From Jeff Miller* The theme of server-side rendering comes as a reaction against React as a super-heavy client framework hostile to most of the world's web client software.
*18:11:14 From Brian* Reacted to "the https://htmx.org..." with 😀
*18:11:48 From Jeff Miller* Good point, Jan, HTMX is an interesting variation where the DOM is being switched out in little pieces of HTML, as I understand?
*18:11:50 From jan dittrich (er/he|they)* Replying to "the https://htmx.org..." same guy who wrote https://grugbrain.dev/ which I find useful
Replying to "Good point, Jan, HTM..." I think so… Have not tried it yet, but it seemed to be an update to the "old style" progressively enhancing use of JavaScript
*18:13:41 From Jeff Miller* Ward reflects on the new world of having a 24-7 accessible server which collects data which can be revisited for processing and exploration at any point, with small scripts (early days on the Internet)
*18:14:16 From Brian* I made a "viewer" for fedwiki in PHP in about 1000 lines, so the server doesn't have to be that complicated...
*18:14:18 From Jeff Miller* http://start.fed.wiki:80/view/seventh-floor "99 bottles of beer" song using "Sing Another Verse"
"the same page, rendered differently each time, because it specifies a computation and does not perform it until it's rendered."
*18:15:24 From Jeff Miller* it looks to the left in the lineup for the previous verse
*18:16:28 From Jeff Miller* when you run out of beer in the kitchen, you pull another case?
*18:16:34 From Brian* I think FedWiki state stayes in client and experience state stays in client.
*18:17:08 From Jeff Miller* Paul reflects on what happens when you move the pages around and they get re-rendered - if we lean into server-side rendering, what happens to the bottles of beer?
*18:17:11 From Brian* And server side remains nearly stateless.
*18:18:05 From Jeff Miller* If we want a format different from the lineup, what does it mean to look at the lineup? (Ward imagines Bret Victor territory - manipulating active objects)
*18:18:12 From Eric Dobbs* Replying to "Good point, Jan, HTM..." I remember writing code in this style in my early days of web apps. My memory of the original motivation was related to inconsistencies in browser implementations of javascript. Browsers were more consistent in their HTML rendering, so it was easier to get dynamic things working with a minimal javascript that replaced a section of DOM with new HTML fragments from the server. There were different complexities in managing the inventory and entanglement of HTML fragment generators.
*18:18:40 From Jeff Miller* Paul reflects on the Ink and Switch mechanism of moving and bumping things which update mutual staet.
*18:18:43 From Brian* Datablocks wiki pages...
The UNIX CLI remains viable as a powerful solution because of ease of composition.
*18:19:18 From Jeff Miller* Replying to "Good point, Jan, HTM..." nods in my "Javascript against the DOM" mini-apps
wondering now about how D3 would imagine wiki implementation
*18:21:35 From Jeff Miller* Ward reflects on the different approaches taken by Mastodon servers to serve different communities.
Also using Mastodon servers, each as a nexus for topics and common interests, when searching for interesting content.
*18:22:41 From Jeff Miller* "this interesting person, what is their site? what other people are on this site?"
Mastodon instances are manually moderated and federated (or de-federated) by their site operators.
oh right the seachanger org quote?
*18:23:56 From Jeff Miller* "Find five friends who want to do fifteen minutes of work every month." - Mastodon small-instance maintenance.
("neighborhood scale site" ?)
the social media termite mound has been kicked over
*18:25:04 From Jeff Miller* (Twitter exodus to various places)
*18:25:06 From jan dittrich (er/he|they)* Replying to "Good point, Jan, HTM..." Peter Paul Koch had a great book on that JS style. I looked up HTMX and it seems that what I though of is alpine.js, which is what can be used for simple front-end-enhacement. HTMX is compatible with that and is a standardization of dealing with AJAX data exchange.
Replying to "Good point, Jan, HTM..." (HTMX’s predecessor, intercooler.js had the tagline "AJAX with attributes")
*18:26:02 From Jeff Miller* Reacted to "(HTMX’s predecessor,..." with 👍
18:29:33
*18:29:33 From Jeff Miller* I actually gave myself a little Oppenheimer-lite
*18:31:24 From Brian* https://www.youtube.com/watch?v=zRTJ5ISmVXE stabilized sky timelapse crater lake.
*18:31:45 From Paul Rodwell* https://www.space.com/james-webb-space-telescope-heavy-cosmic-seeds-early-universe
*18:32:10 From Jeff Miller* movies as a dramatic realization of people's imaginative thought processes without having to have the things explained
(a discussion of the Oppenheimer movie)
*18:32:40 From Brian* https://ia600508.us.archive.org/21/items/the-los-alamos-primer-robert-serber/The_Los_Alamos_Primer_-_Robert_Serber.pdf was a book by Openheimer and fascinating the state of things to kick off Manhatten project.
*18:33:16 From Jeff Miller* "very good at conveying the consequences of what the Manhattan project was about"
*18:33:51 From Brian* Replying to "https://ia600508.us...." Maybe Oppenheimer didn't write it and I was mistaken...
*18:34:05 From Jeff Miller* (despite historical inaccuracies, the feeling of the content and topics is well-portrayed)
*18:34:38 From Paul Rodwell* Replying to "https://ia600508.us...." https://en.wikipedia.org/wiki/Tube_Alloys
*18:34:53 From Brian* https://en.wikipedia.org/wiki/Samuel_T._Cohen was an interesting character.
*18:34:58 From Jeff Miller* I have a brown felt hat and sometimes think of J. Robert Oppenheimer. My grandfather smoked a pipe, but didn't wear that sort of hat.
"technically sweet" as a phrase attractive in grand endeavors.
*18:35:27 From Brian* Replying to "https://en.wikipedia..." His autobiography https://web.archive.org/web/20070928093540/http://www.athenalab.com/Confessions_Sam_Cohen_2006_Third_Edition.pdf
*18:37:18 From Jeff Miller* and then there's J. Robert Oppenheimer's brother, who was blacklisted from academia and gave us the Exploratorium.
*18:37:34 From jan dittrich (er/he|they)* https://de.wikipedia.org/wiki/MIT_Radiation_Laboratory
*18:37:56 From Jeff Miller* Vannevar Bush, "As We May Think" - a loose connection to the Manhattan project (Ward's recollection)
*18:39:05 From Jeff Miller* Dijkstra's attitude on software as being easy to do badly, vs. Douglas Engelbart's vision of "bootstrapping the intellect of the world" by connecting intellects across the world.
(Ward's reflections)
Dijkstra: purity and provable results (Ward reflects on TDD as an incremental hack influenced by Dijkstra)
*18:40:24 From Jeff Miller* Englebart: (Ward reflects on an influence on Wiki)
*18:40:48 From Paul Rodwell* https://en.wikipedia.org/wiki/Edsger_W._Dijkstra#Character
*18:41:18 From Jeff Miller* programmers with no patience for the mathematical proof approach
*18:42:17 From jan dittrich (er/he|they)* German Wikipedia claim that N. Wirth said that Dijkstra noted, when developing the Eindhoven Multitasking OS, that he was not able to work in teams.
*18:42:35 From Jeff Miller* Eric recalls Alan Kay advancing "units of Dijkstras" for programmer arrogance.
*18:44:00 From Jeff Miller* "all of your favorites are problematic", I think, often
*18:45:09 From Jeff Miller* Ward, Nick, Paul, Eric - early gathering of the decaffeination working group.
Starting with the code in "render", which is used many places in the client.
*18:46:48 From Paul Rodwell* The decaffeinate leaves a header with link to suggestions detailed in https://github.com/decaffeinate/decaffeinate/blob/main/docs/suggestions.md
*18:47:23 From Jeff Miller* Nick's approach to callbacks and promises - "when we call the callback, also resolve the promise" - support both calling styles (async / await and callback-passing).
the platform advances and provides more than it used to!
(drifting away, or keeping up with Javascript's evolution)
*18:48:50 From Jeff Miller* all that work by the old Smalltalk hands on Javascript, like Allen Wirfs-Brock on ES6
Marc asks: is there a graph representation for the things you're keeping track of? A state-of-the-whole for the Javascript client code base?
*18:50:04 From Jeff Miller* Ward reflects: Yes, it's probably possible, especially now that it's not mixed-source.
*18:51:35 From Jeff Miller* Paul reflects on using a Javascript language model - converting from Node events to browser events - that the LLM integration, when asked highly-focused questions, is useful.
*18:52:12 From Andrew Shell* I have to go. See you all later!
*18:53:03 From Jeff Miller* Ward reflects on Nick's approach as one which an LLM would be unlikely to come up with.
Eric reflects that Nick is already in-context with when you might use the special trick to support both async/await and callback mode - because it comes with evolving professional-level Javascript code bases.
*18:54:50 From Jeff Miller* (the right person to have in the room)
CoffeeScript and jQuery - good decisions at the time, which are currently holding back FedWiki client development.
18:58:31
*18:58:31 From Jeff Miller* (a discussion of wiki as document? as model? as an agreed consensus, whose results are accepted, related to that consensus? - Ward and Marc)
Marc's experience with Object-Process Methodology, where there is a model diagram which can be visualized and composed / recomposed / manipulated, which then can be rendered as a description and as executable code.
*19:00:03 From Jeff Miller* Marc's experience with wiki as a collaborative, co-modeling environment for people who are working together.
"now make water flow through this model, now make money flow through this model" - can we tie the common understanding of the model to coordinated action?
*19:01:27 From Jeff Miller* http://plumbin.ward.wiki.org:80/ - object-oriented grid computing
"the model knows about water flow, the view knows about rendering pipes and water, the controller lets you move pipe tiles around", to re-compose the model and generate a re-computed view
*19:03:23 From Jeff Miller* Ward demonstrates a pressure tank as a time-dependent part of the model
*19:03:39 From jan dittrich (er/he|they)* Have to go to eat dinner -- see you!
*19:03:57 From Peter* 👍
*19:03:58 From Jeff Miller* "here's a water supply, here are connecting pipes, here's a pressure tank, here's a faucet"
Eric reflects on model-view-controller as an unfamiliar approach to structured programmers; that Plumbin' is a working demonstration of the MVC approach.
*19:05:06 From Jeff Miller* "a correct-enough model that you could feel it working"
*19:06:36 From Jeff Miller* five of six recommendations from Kent on the original Smalltalk Plumbin' code were really good; and this was the start of Ward and Kent working closely on teaching Smalltalk
*19:07:41 From Jeff Miller* Ward reflects an application of a Plumbin' style approach it Dow Chemical, where each module could display its status in factory process control. "After seeing what you did, I went back to the team and used this approach."
*19:07:41 From Brian* ladder logic pieces...
*19:08:00 From Jeff Miller* ladder logic, so different from most programming models
*19:09:06 From Jeff Miller* Eric reflects: OOP as an emergent-behavior approach, suitable for things where structured programming would do different things.
Eric thinks of Smalltalk as an environment where events are flowing, rather than the structural approach where the program is pre-defining data and control flow according to plan.
*19:10:25 From Marc Pierson* Were is the code for the hydraulic “game” in gethub? I cannot find it.
*19:10:47 From Jeff Miller* Ward recalls the "Waterworks" tile placing game, and a visit to the Lisp expert systems lab, where they had a "Truckin'" game for scheduling flows of materials.
"Plumbin'" is a nod to "Truckin'"
(Truckin' is a demonstration of how to use and compose expert systems in Lisp; Plumbin' is a demonstration of how to use MVC in Smalltalk)
*19:11:46 From Marc Pierson* I don’t think the code is in github.
*19:12:56 From Brian* http://plumbin.ward.wiki.org/view/welcome-visitors/view/plumbin-by-example/view/plumbin-download might be the smalltalk version...
*19:13:11 From Ward Cunningham* https://github.com/WardCunningham/assets/tree/3a033220bf901c5b953332046d926f2e2d1dec1b/pages/plumbin-in-wiki
*19:13:56 From Paul Rodwell* the rules for the card game - http://richard_wilding.tripod.com/waterwrules.htm
*19:14:33 From Peter* "bio-break"
*19:17:01 From Jeff Miller* wiki-client v.0.28.1 - 2023-11-23
19:20:38
*19:20:38 From Brian* Maybe moasic the browser...
*19:20:44 From Jeff Miller* oops the radio echoes made me fade out and back
yes NCSA Mosaic the browser
worse lighting better signal here
*19:22:07 From Paul Rodwell* mosaic - as in a picture made of tiles - I suspect
*19:23:04 From Brian* Reacted to "mosaic - as in a pic..." with 😀
*19:23:20 From Jeff Miller* sudo npm install -g wiki - okay, here goes
*19:24:17 From Paul Rodwell* Replying to "sudo npm install -g ..." I won’t tempt fate by saying “What could possibly go wrong”
*19:26:02 From Jeff Miller* /*! wiki-client - v0.30.0 - 2024-08-17
looks like it worked
*19:26:27 From Paul Rodwell* Reacted to "looks like it worked" with 🎉
*19:26:36 From Jeff Miller* when one has not been a professional sysadmin this millennium
speaking of melting ice floes
*19:27:51 From Jeff Miller* fortunately I was early in enough on the job control language that didn't change a lot (BSD / SysV -> Linux)
*19:29:05 From Jeff Miller* nohup sudo wiki -p 80 --allowed '*' --data /home/wiki/.wiki -f (etc. etc.)
19:32:26
*19:32:26 From Robert Best* I needed to order a specialty plastic barbed tee recently...this made me wonder the quality I could get out of a home-grade 3d printer. If the tolerances would be acceptable to just work to grip a hose .. or would it collapse because the plastic is too soft?
*19:32:33 From Jeff Miller* assets/pages/plumbin-in-wiki/mosaic.html (a frame script approach)
*19:34:05 From Robert Best* That would be like a cross with Minesweeper :p
*19:34:51 From Jeff Miller* mine-flusher?
*19:34:57 From Robert Best* This is how mechs could plug together :P
*19:35:09 From Jeff Miller* wiki-mech tiles?
🙂
*19:35:46 From Robert Best* Was playing with a node-red instance recently and thinking how it could work with wiki and things like mechs.
*19:35:46 From Jeff Miller* the hydraulic model of current flow?
*19:37:54 From Robert Best* The pipes reveal how money was previously being laundered.
19:41:25
*19:41:25 From Jeff Miller* "can you render an item with a plug-in, outside the context of rendering into a page / rendering into a line-up?"
*19:41:48 From Robert Best* I guess that would also enable other forms of transclusion within the federation.
*19:41:52 From Jeff Miller* (Marc's inquiries folding back into the earlier discussion from Andrew Shell and plug-ins)
*19:43:00 From Jeff Miller* The browser connects two windows by having one window create the other page, as a security measure
Paul reflects on a common server being necessary for pages to interact with each other directly.
*19:44:01 From Jeff Miller* (for example, using Croquet as a common event bus)
clickable SVGs presented via the HTML plugin (or the graph plugin?) - graphs as navigable interaction maps
*19:45:29 From Jeff Miller* Eric notes: the frame plugin does the translation; the resulting SVG is presented via the HTML plugin
bigger pages for the diagrams, outside of the Miller Columns line-up; is there something in the client that lets every paragraph have a "view navigation" to pop up
*19:46:54 From Jeff Miller* muses in "well, we do have the Lineup Graph plugin"
*19:47:40 From Robert Best* Could the frame plug-in piggyback over miro and do things in parallel with the mouse events etc? I.e. read element/node text like with graphviz.
*19:47:40 From Jeff Miller* graph-wiki as an auxiliary navigation view?
(like imported Arrows diagrams being wiki-fied)
(Paul's note about Arrows import as connecting up wiki references during import)
*19:48:53 From Jeff Miller* Ward reflects on the pop-up view as specially engineered
Maybe we need a zoomable pop-up view with navigation affordances.
Eric demonstrates a linked graph
*19:50:36 From Jeff Miller* https://wiki.dbbs.co/view/enrich-any-svg/view/graphviz ...
oops
let's see what edit-the-chat shows up as in the transcript
https://wiki.dbbs.co/view/enrich-any-svg/view/graphviz/view/reflections-on-graphviz-plugin
*19:51:54 From Robert Best* I edited earlier too :P
*19:52:30 From Jeff Miller* Marc asks: would it be possible to have a large pop-up window being interactable, connected with the lineup, for imported graphs, not just GraphViz items being clickable?
Ward reflects: this depends sensitively on the message interface between the pop-up view and the item within the page in the line-up; the solution may not be general
(not a generative mechanism)
*19:54:12 From Jeff Miller* "application programming" (problem-specific approaches, solutions) vs. "platform development" (general mechanisms, working for most cases)
"The use case is sufficiently different that you have to engineer the message protocol specific for this case, while supporting the main line-up protocol and not messing it up."
*19:55:38 From Jeff Miller* "Enrich Any SVG" collapses it into the size of a wiki page column.
19:58:37
*19:58:37 From Jeff Miller* The risk of a one-off implementation ... our enriched SVG inside the page follows our convention for internal links; it's built to be understood by the HTML plugin, to send a message to the lineup. It uses special conventions for internal links to make sure they dispatch directly. Is that a pattern we could repeat, so that the embedded SVG has "hooks" for popping up a similar view to the GraphViz plugin? - it's definitely hacky, but may be in reach without creating too many commitments in the data to permanently supporting them.
(Eric's reflections)
*19:59:42 From Jeff Miller* Ward reflects: there's a way to have a FORM ACTION create new pages, so there are ways to provide special behavior with a small amount of code.
Brian imagines: should a pop-up connect via a relay agent to the line-up? That's a bit like a multiple-subscriber model, which might end up being complicated to manage, and avoid duplicate messaging.
*20:01:04 From Jeff Miller* Decorator / Proxy metaphor for what the pop-up needs?
(a type-through keyboard cover, for example)
*20:02:23 From Jeff Miller* Eric points to the code in the HTML plug-in which makes an enriched SVG clickable within the line-up, by hijacking the click operation for an enriched, linked SVG element to dispatch into the lineup.
*20:02:31 From Paul Rodwell* https://github.com/dobbs/wiki-plugin-graphviz/blob/main/client/dialog/index.html
*20:02:58 From Jeff Miller* Brian wonders: would it be possible to use CSS to render the pop-up differently?
(Eric and Paul reflect on the old pop-up which was limited to the size of the original wiki lineup window, not a separately movable pop-up)
20:06:37
*20:06:37 From Jeff Miller* Eric reflects on what code would have to be adapted to create pop-up full-size SVGs, by analogy with the GraphViz pop-up interacting with the wiki lineup. GraphViz plug-in: event dispatch / event filtering ("where is this event coming from? the frame? elsewhere?") A form handler in the Frame plug-in, separate from the other form handler; it's difficult because we design for fedwiki-client being a platform.
"The Frame plug-in is a success; the messages in Frame should be promoted to first-class messages in the client." - deferred elevation of the code from Frame plugin to core.
*20:08:38 From Jeff Miller* Time to stay focused on the decaffeination project now; and then moving the Frame protocol into the client protocol. Does that make Frame into a built-in rather than a client? Does that then restrict the flexibility of how we can use the Frame plug-in?
"the whole and the parts" from Follett (Marc)
*20:09:41 From Brian* Another case of "easy to ask questions don't necessarily have easy to answer questions."
*20:09:44 From Jeff Miller* https://en.wikipedia.org/wiki/Mary_Parker_Follett (parts and whole)
*20:12:09 From Jeff Miller* The creative power of the individual appears not when one dominates others, but when all unite in a working whole. - Follett, Community as Process, from M. Zanini. https://www.michelezanini.com/mary-parker-follett-the-first-prophet-of-management/
*20:14:10 From Jeff Miller* Ward relates the evolution of the Supercollaborator (Croquet enabled version) into the Solo Collaborator as a process that was modest but possible, given help with Paul for how to integrate it into a tool within FedWiki.
"all webapps, one way or another; building from its existing messaging structure into messaging from another window"
*20:15:48 From Jeff Miller* "We have this messaging implemented in three different places -- the solo collaborator, the graphviz plugin, the frame plugin -- but not the pop-up code." (paraphrase)
messaging-between-windows: we have three examples, how can we generalize?
*20:18:01 From Marc Pierson* https://marc.relocalizecreativity.net/view/whole-in-each-part/newstate.relocalizecreativity.net/whole-in-each-part
*20:18:11 From Jeff Miller* Reacted to "https://marc.relocal..." with 👍
*20:20:34 From Marc Pierson* Wow, we are willing to collaborate in games but not so much in neighborhoods and businesses.
*20:20:47 From Jeff Miller* "if we want a generic wiki-client which has parts talking with one another via a messaging protocol, that message protocol is a core part of the design" - and those decisions enable or rule-out options for creatively extending the client
can a line-up be nonlocal?
can we bump page items together in an infinite canvas?
*20:22:29 From Jeff Miller* Ward reflects on the Croquet demo -- "see, this is the same fountain here on my phone, there on yours..." (demonstration of the Croquet reflector process)
Croquet reflector = edge networking
(speed-of-light latency limits)
*20:24:12 From Jeff Miller* rearranging the line-up causes a refresh and sometimes a re-fetch (shared objects, etc.)
Marc considers: how about an interactive roster of wiki sites?
*20:25:31 From Jeff Miller* Ward reflects: what would do the coordination is a server-side mech, for having these pages being interactable and shared.
The next step, beyond a demonstration, was not obvious; however, it did demonstrate that a coordination approach for a "collaboration mech" would work. "Anything you do to the right side of the mech will be shared"
*20:27:12 From Jeff Miller* Ward says: because the mech is its own plug-in, it can do things that the Frame plug-in can't do by itself.
*20:28:15 From Jeff Miller* Ward and Marc reflect: the shared context of the pages among the participants would be a way to negotiate contracts in the RenDanHeYi since, visible to all participants, and sign-able as steps are completed.
"the RenDanHeYi sense" (s/since/sense)
*20:28:43 From Marc Pierson* https://contract.relocalizecreativity.net/view/welcome-visitors/view/contract-template/view/rc-rs-contract/view/emc-contract
*20:29:08 From Jeff Miller* "a single site expresses a moment in reality" - Ward reflects on the mechanism for recording an agreement in wiki
Similar to the protocol of doing a checklist on paper.
*20:29:44 From Robert Best* The collaboration mech could be a browser plugin, then it could help you collaborate on any webpage, and shoot data from any tab back to your wiki of choice :P
*20:29:52 From Jeff Miller* Twins protocol updates (Paul)
Desmond and Molly? Happy Ever After in the Marketplace?
*20:31:29 From Jeff Miller* "Where the participants have agreed is captured" ( in a signed set of pages. )
fedwiki-as-a-platform fedwiki-as-an-application (for community collaboration) template pages, boilerplate and examples
20:34:52
*20:34:52 From Jeff Miller* "here's a set of pages for a wiki for this customer, sharing for collaboration" "here is an agreement for how we track collaboration" (like the Plumbin' model as a visual depiction) except using that notion to show an updated contract for tracking collaboration and progress and status. "Data on a page, and we sign that page as an agreement." "here's another wiki with a different project and different customers"
dashboards (makes an "enterprise software" face)
*20:36:17 From Jeff Miller* "The agreement is reflected by passing a page back and forth with our cryptographic signatures." - a separation between the live diagram, and the signatures supported by the platform as a mechanism.
*20:37:29 From Jeff Miller* Eric pulls out a key insight from Ward. "the dashboard that helps me monitor progress on the work" "the document-centric workflow of contract agreements"
*20:39:01 From Jeff Miller* Eric recalls the hypercollaborator, collaborating on graphs; the actual collaboration never really took root. Ward reflects on the learnings - people didn't want to collaborate with graphs, they didn't know how to express themselves in graphs?
Eric brings back the notion of the ActivityPub protocol of "almost realtime" collaboration -- a mechanism similar to email, store-and-forward, but with notifications for prompting "check for updates".
*20:40:11 From Marc Pierson* Discord is used a lot in Superior.
*20:40:41 From Jeff Miller* Discord groups/sites/servers are more turnkey in that sense.
*20:40:47 From Marc Pierson* How is Mastodon different from Discord?
*20:40:58 From Brian* fedriver is closest to that...
Discord is much more "private" than Mastodon is.
*20:41:41 From Jeff Miller* Discord = corporation, first-one's-free, fun youth focus, also adopted by small development communities like the Glamorous Toolkit folks.
interaction-group-as-a-service
*20:43:05 From Brian* I like the mastodon clients way better than discord clients that seem to update every 2 days...
*20:43:16 From Jeff Miller* Mastodon = individual or medium-big group, you can run your own instance and federate to interact, or you can join a server (one or more servers) where your friends / colleagues have already joined, and then you get feeds of content from other servers which this server's members interact with.
*20:43:36 From Marc Pierson* # STAGES AND PHASES This new platform's functionality will unfold in three stages: 1. visual tools for discovery and diagnosis, 1. visual tools for design and development, and 1. visual tools for managing and operating day-to-day.
https://marcus.relocalizecreativity.net/view/neighborhood-mapping
*20:45:14 From Jeff Miller* Mastodon takes more to run your own server or to run a group server; Hachyderm has been pretty open about their process and evolution as they picked up a lot of the Twitter exodus.
("takes more" ~ it takes a while to get to the place where it's five friends and fifteen minutes every so often)
*20:46:08 From Brian* I follow many hachyderm members and really liked their founding and organization. I really like Jerry's admin on infosec.exchange too.
*20:47:20 From Jeff Miller* (looks at the clock, blinks)
9am on Sundays, US-Pacific, give-or-take
20:49:55
*20:49:55 From Eric Dobbs* https://en.wikipedia.org/wiki/Cant_(language)
*20:50:12 From Jeff Miller* Winograd and Flores, Speech Acts
*20:51:16 From Jeff Miller* Richard Cook, "Being Bumpable" - a paper, what is the notion for being bumpable? can you be bumped from the room if it's needed for an urgent case?
(from Eric, about coordinating action in a hospital)
*20:52:17 From Jeff Miller* Study the language, learn about coordination.
"jargon, argot, ... cant" ^ Wikipedia
invented language for including or excluding other out-of-context humans
*20:53:22 From Jeff Miller* "shibboleth" -- ways which express you're an insider (etc.)
*20:54:04 From Marc Pierson* https://marc.relocalizecreativity.net/view/speech-acts
*20:54:13 From Jeff Miller* fraternities and sororities have insider signals
(I met an engineer who had a fun time giving me the signals and seeing that I did not notice them at all)
*20:56:06 From Jeff Miller* "argot", from des argotiers, the folks seeking the Golden Fleece
digital signatures == a focus point for attention before agreeing to sign
(in Marc's notion for coordination)
20:59:53
*20:59:53 From Jeff Miller* "a document" prose "a conversation" poetic interaction?
*21:01:24 From Jeff Miller* capability-based vs. opportunity-based maybe?
*21:01:56 From Brian* I need to do some weekend things...great confervation and excited to see the decaffeination work.
*21:02:24 From Jeff Miller* I guess PixieReport took ten years
but it would have been much faster if I didn't have to wear all the hats.
*21:04:10 From Paul Rodwell* https://thefutureoftext.org/
21:06:42
*21:06:42 From Jeff Miller* Reacted to "https://thefutureoft..." with 👍
Wikipedia's template structure as an affordance for being broadly useful, recomposable, and suitable for translation.
*21:07:58 From Jeff Miller* Ward reflects on ESRI vs. OpenStreetMap
"things" "ways between things" in OpenStreetMap
*21:08:31 From Marc Pierson* https://marc.relocalizecreativity.net/view/pattern-template/view/storycraft
*21:08:45 From Jeff Miller* in some sense there is a single world map; but there are overlays and annotations which can be richly composed
inviting to many participants, using the same form and structure
"how steep is the hill", an annotation on a bikeway
*21:10:30 From Jeff Miller* (a spin-off discussing what makes text persist, long-term)
"a pattern language template", "a story template" - Marc (each of these is isomorphic)
What makes a FedWiki page powerful and useful?
(the WHAT more than the HOW)
*21:11:40 From Jeff Miller* an opinionated guide to how to write pages;
the heritage of Pattern Language pattern templates
dry and repetitive, like a survey questionnaire;
*21:12:48 From Jeff Miller* versus (says Marc), tests for "is this a pattern that follows the essentials?" - a test
"problem, context, solution"
Ward suggested, in the call for proposals for the first PLoP, that if you had a pattern for how to do something, and you wanted to tell your younger brother who was just starting in the job - explain the pattern in this way.
21:15:20
*21:15:20 From Jeff Miller* If you could imagine giving concise advice to someone in solving real-world problems, that was a guide to writing your pattern.
"What did you learn, solving this problem in context, that you wouldn't expect from your preparation?"
*21:16:04 From Marc Pierson* https://marc.relocalizecreativity.net/view/helping-your-kid-brother