GithubHelp home page GithubHelp logo

dalten-collective / gora Goto Github PK

View Code? Open in Web Editor NEW
21.0 21.0 4.0 1.76 MB

A Proof of Attendance Token for Urbit

hoon 87.43% Shell 0.22% JavaScript 0.21% HTML 0.04% Vue 8.82% TypeScript 2.58% CSS 0.71%

gora's People

Contributors

rabsef-bicrym avatar vcavallo avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

Forkers

tinnus-napbus

gora's Issues

Option: Remove Host ability to dictate public

Currently, host and client must mark a gora as public for it to appear in the public list - this has resulted in a lot of confusion and extraneous code, to boot.

Should we allow users to mark ANY gora they own as public? Is there still a good rationale for allowing a host to not publicize their secret gora?

stackable gorae (coup)

I can create a gora called "My Coup Token" and, any time someone does something nice for me, I can give them that coup token - issuing it more than once to the same person, should they deserve it.

A coup gora lets me count these plaudits I give to my friends, and tracks by date when I gave them (perhaps w/ a note?!).

Maybe, eventually, I can trigger behaviors against these plaudits - like send them 5 bucks in ether for each 10 they get, or something.

NeuGora Front End - JS

Javascript Front End Support

Basic Pattern

Subscribe to /website to get the current state. The state will be:

{
  pita: [  {type: 'g', pic: '', name: '', made: <seconds>, id: '', host: '', max: ~ || int, hodl: [ship]}  ||
           {type: 's', pic: '', name: '', made: <seconds>, id: '', host: '', stak: [{who: '', has: int}], nul: ~ ||[array type-g gora]}
        ],
  owned: [<array of ids of gorae you own>],
  made: [<array of ids of gorae you made>],
  public: [<array of ids of gorae you have public>],
  policy: [{id: <gora id>, policy: <bool - T for auto-approve, F for auto-reject>}],
  tags: [{tag: '', id-list: [<array of ids of gorae with that tag>]}],
  logs: {  offers: [<array of gora ids you've been offered - these will be available in pita>],
           requests: [{requester: '', id-list [<array of ids they've asked for>]}],
           outgoing:  [{when: <seconds>, id: <gora id>, who: '', act: 'give' || 'take' || 'gack', status: ~ || bool,
        }
}

Each time an action is taken you will receive a {diff: {add: <state>, rem: <state>}} which you should process, rem first, by deleting from state and then adding to state (from add).

Pokes

::    interacting with gora:
::  [%ignore-give @uv]             ignores a given gorae
::  [%accept-give @uv]             accepts a given gorae
::  [%ignore-request @uv @p]       ignore pleas for gora
::  [%accept-request @uv @p]       accept pleas for gora
::  [%send-gora @uv (set ship)]    give a gora to people
::  [%send-plea @uv @p]            ask ship for gora @uv
::  [%kick ~]                      maybe gora is naughty
::
::    making & changing gorae:
::  [%rm-gora @uv]                               deletes a gora, local or remote
::  [%set-max @uv (unit @ud)]                    sets max hodlers, gora-standard
::  [%add-tag @tas (set id)]                     adds a tag across a set of gora
::  [%rem-tag @tas (set id)]                     remove a tag from a set of gora
::  [%stak-em (set id) @t @t]                    convert a set gorae into a stak
::  [%set-pol @uv u?(%approve %decline)]         (un)set a gora's request policy
::  [%mk-gora @t @t ?([%g hodl max] [%s stak])]  start a new gora with hodl/stak
::

[%ignore-give @uv]

{  ignore-give: { id: <id as string> } }

Should remove an offer from offer log, but not from Pita - you can delete it if you want tho.

[%accept-give @uv]

{  accept-give: { id: <id as string> } }

Should accept an offer, sending a gack, which will be reflected in outgoing.logs as ~ until it has been ack/nack'd and then TRUE or FALSE, respectively, thereafter.
Should result in your gora showing up as yours shortly thereafter (but not instantly - we don't inject ourselves, I don't think).

[%ignore-request @uv @p]

{ ignore-request: { id: <id as string>, ship: <ship as string> } }

Should delete a request for a gora.

[%accept-request @uv @p]

{ ignore-request: { id: <id as string>, ship: <ship as string> } }

Should accept a request for a gora. If it is a gora-standard, it will add them to hodl; if a gora-stakable it will increment their number.
Should delete the request from logs after accepting.

[%send-gora @uv (set ship)]

{ send-gora: { id: <id as string>,  who: [<list of ships as strings>] }

Sends an offer to a group of people - will handle the logic of how to add them, how to offer to them.
Returns an updated outgoing.logs.
Maybe returns an updated gora.

[%send-plea @uv @p]

{ send-plea: { id: <id as string>, host: <ship as string> } }

Sends a request to someone and tries to subscribe to the gora.
Later returns a gora - but not right away there.

[%rm-gora @uv]

{ rm-gora: { id: <id as string> } }

Removes a gora. Returns a gora to delete. Maybe deletes some requests.

[%set-max @uv (unit @ud)]

{ set-max: { id: <id as string>, max: null || int } }

Sets the max possible gora on a gora - if null then unlimited. Handles the logic of whether the move is allowed, based on current holders.
Only works on %g gorae
Returns a gora to "add" (a change).

[%add-tag @tas (set @uv)]

{ add-tag: { id: <id as string>, gorae: [<id as string>] } }

Sets tag across all provided gorae.
Maybe returns an updated tag state.

[%add-tag @tas (set @uv)]

{ rem-tag: { id: <id as string>, gorae: [<id as string>] } }

Unsets tag across all provided gorae.
Maybe returns an updated tag state.

[%stak-em (set @uv) (each @uv [name=@t pic=@t])]

{ stak-em: { dez: [<ids as strings>],
             which: <id of extant gora-stakable> || { name: <name as string>, pic: <name as string> }
           }
 }

Takes a stak of gorae (dez) and stacks them into either an existing gora-stakable (which == <id>) or a new gora-stakable (which == { name: '', pic: '' }).
Sends a bunch of deletes of the stacked old gorae.
Returns a new pita and logs.

[%set-pol @uv (unit ?(%approve %decline))]

{ set-pol: { id: <id as string> , pol: ~ | bool } }

Sets a policy - performs internal logic to determine if allowed.
Returns an updated policy.
Maybe returns updated logs.

[%mk-gora name=@t pic=@t type=?([%g hodl=(set ship) max=(unit @ud)] [%s stak=(map ship @ud)])]

{  mk-gora:  {
                name: string,
                pic: string,
                type: { g: { hodl: [<array of ships as strings>], max: null || int } } || { s: { stak: [<array of {who: ship, has: int}>] } }
             }
}

gora and group-store integration

While we already have a crow extension to do at least part of this, it might make sense to simply build the functionality directly into gora, too.

  1. All ships who join a group get a gora
  2. Any ships w/ a gora are allowed in a group

These, in truth, are only very loosely related.

`each` pokes seem to all fail?

on stak-em, this json...

{
	"0": {
		"action": "poke",
		"app": "gora",
		"id": 2,
		"json": {
			"stak-em": {
				"dez": [
					"0v2.athbv.qofst.6dfs2.boik3.skbj7",
					"0v2.bdbf0.9n33c.i0e2h.po3ls.j1r0t",
					"0v2.t04su.63su8.7h6qj.mlkse.8gp0o",
					"0v3.rq7qg.h00k6.hgudf.7iooc.0q3bo",
					"0v5.3gu9k.r42i6.tq3cl.n1pn4.n3ph2",
					"0v1.09fh7.pusqd.o4aqs.rucmc.t0rbl",
					"0v1.cvs4r.o7k99.q543j.enkvt.ttrai",
					"0v6.qqnni.msun1.himuv.jh6ce.16n7g"
				],
				"which": {
					"name": "STAK",
					"pic": "https://picsum.photos/200/300"
				}
			}
		},
		"mark": "gora-man-2",
		"ship": "zod"
	}
}

Fails with:

gall: poke-as cast fail :gora [a=%json b=%gora-man-2]
[%key 'which']
[%key 'stak-em']
/mar/gora/man-2/hoon:<[17 9].[17 23]>
/mar/gora/man-2/hoon:<[17 5].[79 7]>
/mar/gora/man-2/hoon:<[16 5].[79 7]>
/sys/vane/clay/hoon:<[832 51].[832 63]>
/sys/vane/gall/hoon:<[890 27].[890 45]>

mk-gora also fails. json:

{
	"0": {
		"action": "poke",
		"app": "gora",
		"id": 2,
		"json": {
			"mk-gora": {
				"name": "make a stack",
				"pic": "image",
				"type": {
					"s": {
						"stak": [
							"~rus",
							"~sum"
						]
					}
				}
			}
		},
		"mark": "gora-man-2",
		"ship": "zod"
	}
}

Error:

gall: poke-as cast fail :gora [a=%json b=%gora-man-2]
/sur/gora/hoon:<[17 11].[17 25]>
/sur/gora/hoon:<[76 52].[76 57]>
/sur/gora/hoon:<[76 53].[76 57]>
/sur/gora/hoon:<[76 28].[76 58]>
/sur/gora/hoon:<[76 33].[76 58]>
/sur/gora/hoon:<[76 7].[76 59]>
/sur/gora/hoon:<[76 7].[76 59]>
/sur/gora/hoon:<[76 7].[76 59]>
/sur/gora/hoon:<[76 7].[76 59]>
/sur/gora/hoon:<[70 3].[78 5]>
/sur/gora/hoon:<[47 7].[47 18]>
/sur/gora/hoon:<[47 3].[58 5]>
/mar/gora/man-2/hoon:<[16 5].[79 7]>
/sys/vane/clay/hoon:<[832 51].[832 63]>
/sys/vane/gall/hoon:<[890 27].[890 45]>

Public gorae not displayed on public page

Having an issue with the public gora page. When I load the page it says "Owned %gora Click the preview image to see more details." but there's nothing visible below that.

In the dev tools I see that it does have the gora images and if I remove display: none from the modal elements, I can see them.

I'm pretty sure it's just a display bug.

image

EScape by UqbarDAO Integration

Submit a PR to EScape by UqbarDAO providing the following feature-adds:

  1. On clicking a ship's name in a chat, I can click on "Send a Gora" in the contextual menu that displays, and select from a list of my made-gora - this will command my ship to send the ship I've clicked on the gora that I specified.

    •  This should not display gorae that have already reached their max issuance
      
  2. In someone's profile, I can see any gora that I am aware of them possessing (this could use an %x converted version of %check scry) but that only shows public. Maybe we should, instead, make it for any we're aware of them possessing.

  3. Additionally, one could use the primary implementation of %check (a public gora I'm aware of someone else possessing) and shoot out those images to the right of their handle in-line in groups - this is iffy, preferring above.

Tag-based public pages

  1. Let me create multiple public pages, based on tags.
    that is:
  • a public page for TagA
  • a separate public page for TagB
  1. Allow me to choose if a given tag has a public page or not

logs.requests diff missing entries in 'id-list'

After making a plea, i seem to have gotten a dif with this in both set and rem

// other entries elided
{
    "requests": [
      {
        "id-list": [],
        "requester": "~zod"
      }
    ]
}

the initial state looks right though (ignore outgoing):

{
  "offers": [],
  "outgoing": [
    {
      "status": true,
      "when": 1663280096,
      "who": "~zod",
      "id": "0v5.g0tdk.1jkvn.trj0t.nkase.jc51m",
      "act": "take"
    },
    {
      "status": true,
      "when": 1663279404,
      "who": "~sum",
      "id": "0v5.ngk19.hfocl.vqndc.hcsbu.u9ber",
      "act": "give"
    },
    {
      "status": true,
      "when": 1663279258,
      "who": "~sum",
      "id": "0v4.q3qr5.rpkjo.1gc3d.uvma1.mcev4",
      "act": "gack"
    },
    {
      "status": true,
      "when": 1663278979,
      "who": "~sum",
      "id": "0v2c9et.igacf.5v6v0.cemse.p09ge",
      "act": "gack"
    },
    {
      "status": "pending",
      "when": 1663268007,
      "who": "~sogrum-savluc",
      "id": "0v5.g0tdk.1jkvn.trj0t.nkase.jc51m",
      "act": "give"
    }
  ],
  "requests": [
    {
      "id-list": [
        "0v5.g0tdk.1jkvn.trj0t.nkase.jc51m"
      ],
      "requester": "~zod"
    }
  ]
}

Convert %gora sail management to rudder

Rudder obviates the need for large portions of the sail gora implementation.

gora should be re-written to utilize Rudder and save some lines.

This will likely require the custom routing implementation allowing for both public and private pages, which has been explored in ibis, here.

There are feature adds that should also go into this conversion, which I will submit as separate issues, referencing this issue.

UX Demands

There are pressing UX issues with Gora's UX - in the current sail version, content is irrationally exposed in narrow slots to try and maintain a 'short' page, for instance. In implementing a new #5 Rudder sail version, and hopefully through the grace that only a large shipment of prosciutto can buy from @vcavallo, we should also reconsider the User Experience stories:

• First Open
    ◦ I can see that I possess or do not possess some/any gorae
    ◦ I can see that I have created, or have not created some gorae that are still actionable
        ▪ I.E. that have remaining slots in their Max Holders left
    ◦ I can see that I have or do not have some incoming requests for gorae that I’ve made
    ◦ I can see that I have or do not have some incoming offers of gorae to accept or decline
    ◦ I can, from here, choose to interact with:
        ▪ my possessed gorae
        ▪ my created gorae (both those that have remaining space and do not)
            • incoming requests for my created gorae (is this a subset of the above?)
        ▪ those gorae that have been offered to me
        ▪ base operations like:
            • Create a gora
            • Turn on and off usps mode
            • send a gora
            • request a gora
    ◦ *stretch* I can see that there is a way to browse gorae I’ve heard of through `%pals` and Gossip library integration
• “Possessed Gorae”
    ◦ Those gorae that I possess are displayed, sortable/filterable/searchable by name, date of receipt (do we have this?), issuing @p and tag
    ◦ For those gorae where there is a reissue property, I can clearly see that I have the ability to reissue them to my friends, as differentiated from those that do not (if we’re displaying them as cards w/ the circle gorae @ the top, perhaps differentiate by background color)
    ◦ Those gorae that are chain-letters (have %transfer property) are sufficiently separated from the primary field of vision that they do not distract from more meaningful gorae
        ▪ Perhaps they are, themselves a sub-window or another interaction away from this base page of possessed gorae
    ◦ If I both possess and created one of the gorae listed, it should be clear that I can reissue it
    ◦ I can apply a tag to one or a set of gora(e)
    ◦ I can set local-public on one or a set of gora(e)
        ▪ I can differentiate which are currently marked as public and which as private – I should only be able to see/set public on those where the HOST has also marked as public
            • OPTION:
• “Created Gorae”
    ◦ I can see all gorae that I have created, separating %transfer from normal gorae
    ◦ I can click on a gora, resulting in an option to “send to” as well as a better view of the gora itself
        ▪ If the gora is already at max users, “send to” should be clearly disabled
    ◦ Those gorae that I’ve created are displayed (notwithstanding %transfer gorae) in a way that permits me to sort/filter/search by name, date of receipt (do we have this?), the issuer (@p) or tag
• “Base Operations”
    ◦ I have a helpful dialogue walk me through creating a gora. When I complete that dialogue, I’m taken to the “Created Gorae” page w/ the “send to” dialogue displaying for the gora I’ve just created (described above) – this can be done by query param or somethin.
    ◦ I can request a gora by ID (or if we have pals and rumors floating them around, we can click to request)
    ◦ I can send a gora – this will need it’s own page not quite possessed and not quite created, as I may have some exclusive to either category, each of which I can send, properly.

And from all those places... I ... can, uh, get back?

Add `/gora-properties` or similar scry behavior

Responsive to: #4

Need %x scry for /gora-properites/<gora-id> that returns that gora as a gora (just a single cell of data).
Need %y scry for /gora-properties resulting in an arch of [~ [~ (list gora-ids)]]

Purpose:
Allow users to scry individual gorae for their properties out of state so they can diagnose this behavior

On create, the "mint gora" button shows no feedback

Ahoy. Gripe is: I tried to make a gora, but instead I made 20 goras because the submit button doesn’t have any feedback that it works. :)
~ranter-tapper

The "mint" button should deactivate until the creation process completes, and the form should probably clear and auto-collapse

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.