dalten-collective / gora Goto Github PK
View Code? Open in Web Editor NEWA Proof of Attendance Token for Urbit
A Proof of Attendance Token for Urbit
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?
The rm-gora
poke works, but the interstitial warning in the Vue version no longer actuates it.
maybe i'm a dummy. but i don't see a way to close the gora modal on mobile aside from refreshing
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.
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).
:: 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}>] } }
}
}
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.
These, in truth, are only very loosely related.
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]>
Would be cool to get landscape notifications for stuff like new gora offered, X ship accepted a gift, etc.
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.
Submit a PR to EScape by UqbarDAO providing the following feature-adds:
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
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.
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.
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"
}
]
}
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.
Note that there is an issue when handling failure messages that we'll need to sort out.
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?
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
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
description todo
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.