• #39
• #40
• #41

aka continuous integration via GitHub

If so, why?

person removes relationships with self and other agent.

i reckon we should start building up a beautiful source of content for what we're doing here.

ideas:

• holons (i already have some half-written blog posts)
• abstract network roles and relationships
• real use cases of network roles and relationships
• open source cross-project domain-driven development
• learning from valnet's type -> plan -> actual model layers
• data-driven virtual dom views
• immutable data, observable cursors, data history
• transactional data stores with per-agent data provenance

this means including the OPEN open source manifesto in our repo and following it.

an open question is if this conflicts with our copyleft license. one main problem with copyleft is that in order to change the license, you need consent from all contributors, so a while back i schemed on a more copyleft / peer production version of OPEN open source (ahdinosaur/contributing#1 and ahdinosaur/contributing#4) that attempts to implement a contributor agreement via GitHub, but i have no idea if it's a valid approach.

right now it's confusing to see a stewardship relationship because it's not obvious who is the steward and who is the stewardee.

possible solutions:

1. the stewardship relationship type explicitly specifies a directionality (source and/or target role) and we draw a single arrow instead of two arrows
2. the controls show both roles in the relationship, as below:

and we allow selecting and unselecting of those role types, which will update the similarly-colored arrows that are shown.

we could probably combine these two approaches, where we let the relationship type specify which role direction should be shown by default and we let the user update that as they wish.

group admin removes relationships with group and other agent.

deliverables:

• logo
• landing page design
• app style guide
• ...?

value: we can communicate Holodex beyond words.

it's out of date. 📟

high-level user stories:

• user finds (filters) people based on profile information (name, location, tags, etc)
• user finds (filters) people based on relationships (memberships, stewardships, etc)
• user browses people and groups through relationship links
• user sees profile information about person
• user sees profile information about group
• user is not overwhelmed by information overload
• user sees asymmetric and symmetric relationships

person can create relationships with self and other agent

from holodex/app#3.

• GitHub
• Twitter
• Facebook
  etc

kinda like keybase

there's no point in having relationships data when at this point it can all be derived from the @id in the respective people data.

@id will be of the form <is>:<relationship>:<has>

user sets data properties as public or whitelisted to specific agent(s) only.

group admin can create relationships with group and other agent

since relationships involve two or more agents, it's necessary to get consensus on any new or updated relationships.

outline of UX flow:

1. Alice creates a new mentorship relationship with Bob as the mentor and Alice as the mentee. At this point, the relationship is (shown or not shown?) and considered unconfirmed.
2. Bob receives a notification about this new relationship: "Alice has created a new mentorship with you, blah blah blah, do you confirm this is true?". He is given the option to accept or decline.
3. If Bob confirms, Alice is notified as such and the new relationship is shown and considered confirmed. If Bob declines, Alice is notified as such and the new relationship is not shown and considered declined.

from a real metamap, an example of this in action.

this brings up the design question of how best to view symmetric relationships.

/cc @simontegg

:(

group admin can update relationships with group and other agent

maybe for starters we do a simple handle as in holodex/app#3, then later we do more extensive contact info a la https://www.loomio.org/d/7nJLR2gB/idea-allow-users-to-include-their-contact-info-in-their-profiles?

we should write up a simple doc on how edit a person or group data, with the hopes of being able to either allow people to update their own data or have a group admin keep everyone's data up to date.

http://formatjs.io/
http://formatjs.io/react/

should probably store ICU translation messages as yaml files, it'll be interesting to see what tooling develops as io.js is also starting to use the same message format for their translations.

determine locale with http://formatjs.io/guide/#runtime-environments and bundle translations in the page render.

we aren't going to be accessible enough for the general public to use yet, but at least we can be somewhat usable for motivated friendly groups to use.

• write up new user guide
• write up new group admin guide
• write up new host admin guide

related to holodex/app#57 (comment).

creating a new group automatically creates an admin relationship with the creator.

if anyone has any ideas for how we pitch holodex, please share! 🎆

i'm curious if it's possible to pitch holodex by showing off key concepts of the app through visualizations of real networks.

• GitHub repos
• Trello boards

Hi Simon and Mikey, we noticed that Craftodex and Directory UI were deprecated in favor of Holodex. Just curious as to where you guys are going with all of this now, and if you are still using the open vocab for person and organization underneath?

Another thought: Elf and I are going to start in again on the open vocab side, so if you run into anything you want incorporated or don't want incorporated, let us know.

having to manually include links to related objects is a pain (as in groups data), we should be able to automatically derive these relationships.

related discussions:

• #38
• holodex/landing#1 (comment)

deliverables:

• a pitch tagline
• a pitch sentence

value: we can better communicate the value of Holodex.

what success looks like:

With ZeroMQ, we said we were going to make "the Fastest. Messaging. Ever.", which qualifies as a good motivator. If we'd said, we're going to make "a smart transport layer that'll connect your moving pieces cheaply and flexibly across your enterprise", we'd have failed

Then your work must be beautiful, immediately useful, and attractive. Your contributors are users who want to explore just a little beyond where they are now. Make it simple, elegant, and brutally clean. The experience when people run or use your work should be an emotional one. They should feel something, and if you accurately solved even just one big problem that until then they didn't quite realize they faced, you'll have a small part of their soul.

should provide:

authentication = login + password (who you are)
authorization = permissions (what you are allowed to do)

hmm, needs some more hammock cyles. 🎋 an open question is whether this should even be in holodex or whether it should be done as a separate "secure identity vault" app.

relevant:

• https://web-payments.org/specs/source/identity-credentials/
• https://github.com/substack/accountdown
• https://github.com/substack/keyboot
• https://github.com/ssbc/ssb-keys

problem: many group logos cut off in the circle format