If I submit anything other than valid hepped tas-style-names, the poke fails. Is this expected?

There's a reason for this - not wanting to futz with graph-push-hook to have my will be done.

Deal with it, probably. 😎

Front End Testing

Use the included test graphs to complete the following tests.

Included Graphs

Each graph attempts to exercise at least some complexity. There are edited posts in the notebooks, comments in links and notebooks, and deletions in all of them. However, our goal is not perfect fidelity of the medium, but "good enough" fidelity. We cannot accommodate all possible erratic kinds of graph-store content, but we believe we have most of them accurately handled.

Pre-test

1. Use @Fang- 's |new-desk to make a desk called %oger locally on your test ship.
2. |mount %oger
3. Copy the contents of this repo the %oger directory and |commit %oger
4. |install our %oger on one test ship then :treaty|publish %oger on that same ship
5. |install <that-ship> %oger on another ship, so you have two ships running the same copy of %oger

Copy this format into a comment below this head and enter your results.

Import a Chat, Link, Notebook from Disk

• Create a group on your test ships - hereafter a-group and b-group
• Click [Import 📤]
• In the blank for folder (placeholder text my-chat-123), enter a-chat or a-link or a-note (depending on which you want you test)
• Select the local group on your ship (a or b) from the drop down menu
• In the blank for the new-resource's name (placeholder-text my-new-chat) type whatever
• Click [Import 📤]
• This is gonna take a second, incidentally

Results

• I was returned to the home page, with the message 'Import Queued - Response Times May Vary - Check Specified Group'.
• On checking the group I specified, I see the new chat with the messages I expect, in it.
• Deleted messages in chats do not display (Already Confirmed).
• I can perform this same import behavior on a group, hosted by another ship, of which I am an admin

Export a Chat, Link, Notebook to Disk

• Having Imported from Disk above, let's import
• Click [Export 📥]
• Looking through your available resources, export one.

Results

• 🚫 On clicking [Export 📥] I could see all of my graphs, including imported ones. This fails unless you trigger a %keys event, which doesn't happen because I'm not using graph-push-hook - create a chat naturally through the frontend and it'll kick.
  • This is fixable using threads but honestly why bother.
• On clicking [Export 📥] next to a graph, you're able to export it as a file - your dojo will prompt something like:

  %oger-import
  -import-starting
  -group: [entity=~wet name=%b-group]
  -resource: [~zod %fukin-notes]
  

• I am able to find my resource in an appropriately named folder in the /path/to/pier/.urb/put directory
• All of my files maintain a name|graph|type|# format

Permit a Ship to Search You / Deny Them!

Give your partner enthusiastic consent!

• Click [Permit ☑️]
• Type in a @p
• Click [Permit ☑️]

Results

• I get a success message
• If I click on [Permit ☑️] again, I see the person I entered in a list with a 🚫 icon next to their name
• Click [Remove 🚫] next to their name and confirm that it removes them from that list
• Permit your other test ship and confirm in the next step that they can search you

Search a Ship with OgerTalk ™️

• Click [Search 🔍] (the main tile, or enter the ship name that you permitted and click search - but you'll have to do it twice then)

Results

• At some point, after returning to search, I can see my friend's name in the list of ships I know.
• Clicking on the ships name shows me the chats I know about, from them.

Remake a Graph with OgerTalk ™️

This is very much like importing - you should be able to understand the interface from here

Results

• I can remake a graph successfully.
• I can do so to a group I do not host, and everyone can see it.

DM file import will ignore group requirement.

But there is currently no way to export DMs through the UI. need to add this.

Peat has been redesigned in the feature-interface iteration to work using a JavaScript Front End. There are some subscriptions and many json friendly scry endpoints, as documented below

Subscriptions

Subscription path is /website - we should consider that we could have more than one path for this - main data and diffs - if easier to handle. Also maybe other patterns to explore there.

+on-watch (i.e. first watch):

• { 'saved' : <saved> , 'given' : <given>, 'doled' : <doled>, 'known' : <known> }
  • saved - an array of currently tracked, saved chats (that are being auto-exported to disk on x basis. e.g. - an array of:

  {
      'date-of-last-save-as seconds timestamp' : 
      {
          'entity' : <host>, 
          'name' : <graph name>, 
          'frequency' : <frequency of saves>, 
          'last-index-captured' : <seconds timestamp of last post that was captured (bear in mind this doesn't track necessarily w/ the last time a save was attempted)>
      }
  }
  

  • given - an array of graphs that have been shared with you. e.g. an array of:

  {
      '~sahrer-palnet' : 
      {
          'shape' : <%chat, %link, %publish or %dm>,
          'resources' : <array of { 'entity' : '~ship' , 'name' : 'the-graph-name'}>
      }
  }
  

  • doled - an array of graphs you've shared, same shape as given
  • known - an array of graphs your ship is currently tracking in graph store

  {
      <'chat' 'link' 'publish' or 'dm'> : 
      {
          'group' : 'ungrouped' // or { 'entity' : '~zod', 'name' : 'a graph' },
          'resources' : <array of { 'entity' : '~ship' , 'name' : 'the-graph-name'}>
      }
  }
  

Diffs

• [%export *] - Performed both on one-time export, and on the recurring exports (below, showing a 36 hour backup schedule)

  {
      'diff-export' : 
      {
          'resource' : { 'entity' : '~zod' , 'name' : '%a-backed-up-chat' },
          'frequency' : <'once' _or_ { 'days' : 1, 'hours' : 12, 'minutes' : 0 }>
      }
  }
  

• [%cancel *]

  {
      'diff-cancel-export' :
      {
          'entity' : '~zod',
          'name' : 'a-chat'
      }
  }
  

• [%import *]

  {
      'diff-import' :
      {
          'group' : { 'entity': '~zod' , 'name' : 'a-group' },
          'resource' : { 'entity': '~zod' , 'name' : 'a-chat' },
          'path' : '/our/peat/now/hav/imported-resource'
      }
  }
  

• [%permit *]

  {
      'doled' : <same as on-watch, doled sub-element>
  }
  

• [%record ~] - does not fire immediately, instead agent watches another and then gets an

  {
      'diff-hav' : 
      {
          'ship' : '~host-ship',
          'shape' : <%chat %publish %link %dm>,
          'resources' : <array of resources as { 'entity' : '~host', 'name' : 'graph-name'}> 
      }
  }
  

  from on-agent, or, sometimes, a %kil:

  {
      'diff-kil' :
      {
          <same as a hav, but indicating that you no longer have access to those things>
      }
  }
  

• [%remove *]

  <same as permit but indicating a change to dis-include some parties - rather than a true diff>
  

• [%remake *] - not immediately, on receipt of the facts

  {
      'diff-remake' : 
      {
          'group' : { 'entity': '~zod' , 'name' : 'a-group' },
          'resource' : { 'entity': '~zod' , 'name' : 'a-chat' },
      }
  }
  

• [%depart *]

  {
      'diff-left' : '~wet'
  }
  

Scries

• As on-watch:
  • [%x %saved ~] - same as on first load
  • [%x %given ~] - same as on first load
  • [%x %doled ~] - same as on first load
  • [%x %known ~] - same as on first load
• Specify the host/recipient/shape, get interior jug:
  • [%x %given @ ~] - specify a ship and see just the graphs you've had shared with you, from them, paginated by shape
  • [%x %doled @ ~] - specify a ship and see all graphs you've shared with that ship, paginated by shape
  • [%x %known @ ~] - specify a shape and see all groups w/ graphs in that shape, and those graphs (As a mapping thereof)
• Specify the host & shape, or recipient & shape, or shape and (unit resource)
  • [%x %given @ @ ~] - specify host (granting access) and shape, see set resources available of that shape from that host
  • [%x %doled @ @ ~] - specify the recipient and shape, see set resources you've shared w/ that recipient
  • [%x %known @ <~ [@ @ ~]>] - specify the shape and either no or some group, see the resources in that group, of that shape
• Supporting Cast:
  • [%x %hav ~] - all of the backups that have been committed into the /hav directory of the desk, which is where I expect users to load import files (we'll direct them in the %docs)
  • [%x admin ~] - What groups am I an admin in? these are the groups I can add graphs to natively. Otherwise I have to make a new group!

Pokes and Workflow

To understand the available pokes and the workflow of the system, best that we understand the state:

State

• saved (map resource [@da @dr])
  • A map of resources to ['last post indexed' 'frequency of indexing, cannot be less than 1 day']
  • Note: 'last post indexed' could be stale if people don't post frequently - we don't really track the last time the save was run, just the last post we have saved - which could be compared using a scry to graph store (but technically, that's how we get it, not by rolling through the updates we just saved, so it's not gonna help if it's wrong).

The Jag

jags are a new structure for hoon that have their own associated library, /lib/jag/hoon. jags are a (map kex (jug key val)). For each key, you can store a (jug key val), meaning multiple subordinate keys and corresponding sets of values.

• given (jag ship shape resource)
  • A jag of ships who have shared graphs with you to shapes (or <%chat %link %dm %publish>) of graphs, to sets of resources they shared, in that shape.
• doled (jag ship shape resource)
• Same as given, but the other direction - what you've doled out
• known note the different structure here (jag shape (unit resource) resource)
  • This has been restructured for convenience of the user in looking things up (and scrying for the frontend) - you would commonly know the shape you're looking for "I want that chat, from " a group you know (unit resource) called resource. bang, you got it

Workflow

Startup

• Peat records all the graphs you're privy to, puts them in known, and starts watching for changes there.

  Note: Peat takes care of removed graphs by informing people you've shared them with of the loss of that resource

Poke Actions

• Export (to disk)
  • [%export res=resource rec=(unit @dr)]
  • Exports a resource once, or with a frequency set by rec

  Note: Minimum 12 hours, can't set the same time twice - must change.

  • Expected JSON poke structure:

    {
        'export' :
        {
            'resource' : { 'entity' : '~zod', 'name' : 'a-chat' }
            'frequency' : <either 'fuck-you' or 'anything, literally' or '~d1.h2' etc for a time>
        }
    }
    

• Cancel (autosave)
  • [%cancel res=resource]
  • Cancels an existing export procedure (just stops running the timer, doesn't clean up /.urb/put)
  • Expected JSON poke structure:

  {
      'cancel' : { 'entity' : '~zod' , 'name' : 'a-chat' }
  }
  

• Import (from disk)

  Note: [%x %hav ~] scry, which provides you all of the backups you've commited to the /=peat=/hav directory - this is where users should put folders of their backups that they want to import, eventually we'll do that for them.
  Note: [%x %admin ~] scry, which provides you with all groups in which you are an admin, for the purposes of gro=(each resource term).

  • [%import fol=path gro=(each resource term) wer=term]
  • fol should just be the subdirectory of /hav that they want to import, use the scry!
  • gro can be either an extant group of which you are an admin
  • Expected JSON poke structure (new group):

  {
      'import' : 
      { 
          'folder': '/a-chat'
          'group' : 'new-group',
          'new-resource-name': 'new-chat',
      }
  }
  

  • Expected JSON poke structure (existing group):

  {
      'import' : 
      { 
          'folder': '/a-chat'
          'group' : '~zod old-group',
          'new-resource-name': 'new-chat',
      }
  }
  

• Permit (allow others to copy some resources)

  NOTE: Same as remove, so remove is not documented here

  • [%permit per=(set ship) rys=(set resource)]
  • Shares the set rys of resources you have (you must have them, actively, in graph store) with per such that they can elect to remake it if they choose - does not force them to take any action
  • Expected JSON poke structure:

  {
      'permit' :
      {
          'ships' : <array of '~zod' '~wet'>,
          'resources' : <array of { 'entity' : '~zod', 'name' : 'a-chat' }>
      }
  }
  

• Record (learn of an available subscription)

  Note: Not a user action, poking it to yourself won't do anything.

• Remake

  Note: known has all the graphs you're familiar w/ locally, given has those you've been... given
  Note: [%x %admin ~] scry, which provides you with all groups in which you are an admin, for the purposes of gro=(each resource term).

  • Expected JSON poke structure (local resource):

  [%o p={[p='remake' q=[%o p={[p='group' q=[%s p='~zod group']] [p='new-resource-name' q=[%s p='new-res-name']] [p='remake-resource' q=[%s p='~zod old-res']]}]]}]
  

  • Expected JSON poke structure (remote resource):

  [%o p={[p='remake' q=[%o p={[p='group' q=[%s p='~zod group']] [p='new-resource-name' q=[%s p='new-resource']] [p='remake-resource' q=[%s p='~sharer shape ~host resource-name']]}]]}]
  

If I have a resource in the DOG GROUP named pet-chat and I export it, I'll get a .urb/put/pet-chat directory with some contents.

If I have another resource in the CAT GROUP named pet-chat and I export it, what happens to .urb/put/pet-chat ?

contents of /hav:

only one "link" shape item is being returned:

result of :gora +dbug:

We have a delay-card thread for crow that would work fine here, though it could be done more purposefully for this implementation.

Also, I kinda don't want to - it's fine.

• On master branch, remove items from /hav so we don't distribute them

Seems to happen with all resource shapes.

example stacktrace response when trying to import a link collection to an existing group I admin:

/app/peat/hoon:<[783 7].[812 9]>
/app/peat/hoon:<[782 7].[812 9]>
/app/peat/hoon:<[780 9].[812 9]>
/app/peat/hoon:<[780 5].[925 7]>
/app/peat/hoon:<[97 11].[97 54]>
/app/peat/hoon:<[96 11].[97 54]>
/app/peat/hoon:<[88 9].[114 11]>
/app/peat/hoon:<[87 6].[115 19]>
/app/peat/hoon:<[86 6].[115 19]>
/app/peat/hoon:<[84 5].[116 7]>
/app/peat/hoon:<[83 5].[116 7]>
/sys/vane/gall/hoon:<[1.372 9].[1.372 37]>

• insure that <form location="upload"> works in globbed version for file upload (I had to work around this in funny ways to deal with vite proxying, can't test properly in dev)
• remove "dev jams" from distributed desk

the things around admin in this app often only check for name, not also entity. will need to extend that to act on the pair.

DMs don't show up in the UI as something that can be exported. Do we care?

web+urbitgraph://group/~hoster-dozzod-dacwet/urbit-media/graph/~hoster-dozzod-dacwet/dot-7168/170141184505797752106847845419900207104

~ricsul-bilwyt would like an option to export many (maybe all) resources at once.

kicking off many threads may be a good option (and probably the only way to do this i guess). Would likely want to have this work with the filters - that is, apply some filters and then "export all visible" or something.

Graphs shared with us from other users may be partial copies of a large whole. It should be possible to reconcile the best-understanding of a graph, based on multiple shared copies. A (jug [resource shape] ship) is probably sufficient.

Bug report from ~rabsef-bicrym:

• after import, there is an error in js console - maybe about series of keys it doesn't know how to import.
  • when clicking on live, no graphs. after refresh, works, and appropriately grouped.

((probably not appropriately updating the Known store after import))

• remove all console.logs
• some form fields are squished on medium size screens
• some buttons stack when they shouldn't (on med screens too)
• #33

Or some other way to handle this poor UI.

ideas:

• only show group names and resource count in the list, then require choosing single group (like by filter) in order to see resources within
• front-end pagination.

NGINX has a default 1MB upload limit. for a ship on this kind of hosting, uploading a large files of jams will fail.

possible fix: have the front-end upload the jams in x batches under the 1MB limit?

• put name/shape on own row, left'd, above owner (which is still right'd)

• doesn't seem to like zeroes
• leaving out middle steps is okay

Home Page

Search in Remake Mode

Search in Search Mode

That's basically the pattern, repeated elsewhere

• allow for exporting to a newly-created folder on S3 with public read permissions.
• allow for importing from an S3 folder (in addition to from /hav, from upload)

relies on #28

Once pushing to and pulling from an external source is possible (#28), then we could add shareable "template" resources:

A user could create a notebook or collection - perhaps a template for a knowledge base, or a static list of mental health resources for new groups to start with, whatever people might need - then export this set of resources to S3 and create an instance of a (new concept to be built) Shared Collection and optionally whitelist some ships.

Long ago we had discussed a kind of "automated onboarding" that would allow someone to start a group for X concern (the example at the time was local LGBTQ support groups). By installing Peat and subscribing to some known Shared Collection, a newly-formed entity that wishes to provide these resources could do so by importing from said Shared Collection.
Perhaps the "installing Peat and subscribing..." process could even be automated in a custom pill...

When searching for a resource, the text in the search box does not keep up with my typing speed. Once I stop typing and wait ~1 second, all the input text appears at once.

It seems like everything updates all at once, both search results and the text field.