# Rebase Sync

[](https://hackmd.io/4J-b5nkGQZWlQisVruyY6w)

# may 13, 2022
# attendes
- wayne
- orie
- dan
- joel
- oliver
- haardik
- kelsey
- francis kim

# minutes

dan: are there any schemas?

juan: no updates from juan

orie: create profile picture for rebase github

wayne: how would verite interact at all?

juan: will check and has no answer yet.

joel: wanna start with the 2 things to present?

orie: has just done the profile picture. but it is a good idea to give updates on what has happened since last meeting.

wayne: like profile pic

wayne: realising that we have some of the schemas that are jwt and json-ld friendly implemented but are bound to tezos but now in the process of generalizing those what we colelciveltiyl agreed on rebase schemas. turning into rebase frontend and cloudflare backend. would like dapp but no blockchain. user will do twitter verification, tweet it out. cloudlfare worker in the background that works as issuers. really easy to deploy. just a few ocmmands. can also run in standalone binary mode. written in rust and does issuance. everyone can run it. basically the stuff we are working on.

we won't need rebase schemas in there if we use cnc. if there is as dif repo for rebase specifically, that is fine.

orie: we have spec dir and hosting openapi api for the specs. so figuing out why other schema repo.

dan: it is about right but .. what we are tryign to do is one repo in multiformat. interested in schema for this kind of thing. wondering if someone has a place where this is curated which is nice work for me. dif would be the one that does that.

juan: reference vs permanent hosting?

dan: schema dir has two functions, 1) points to other schema objects that are in other schemas, 2) where it does not exist, where no effort as well, one could host them in schema directory.

wayn: next steps will figure out repos for schema in DIF?

joel: schemas will stay in github but there will be additional pointers to schemas but we don't care.

orie: we don't care. can be many pointers.

wayne: rebase.xyz is the topic if final resting place for schemas.

joel: we have also a demo. tldr: github handle, github handle connect to wallet, put in human readable statement. sign over it and put statement and sig and put into gist and get url of gist and gives it to service. service verifies that and issues a vc that follows the schema that tzprofiles usess.

hardik: purpose of this is to get to test vectors asap. minimal implementation. not fancy. but connect wallet, did:pkh is used for eip-155. input github handle, sign from metamask using personal sign. one can add support for more key formats but we wanted to suppport did:pkh specifically. you get this signed doc, it is just a json doc, that gets put into the gist. then this is given to backend service which produces a JWT VC for the github verification. following the tzprofiles schema. client side verification is out of scope of rebase but we have also implemented this. next steps might be discord.

orie: so cool. to verify this if we wanted to commit test vectors to source. problem is to wrap evidence URL location or test vectors are commited to resolving something over the network. we can capture network request and internalize for test vectors or establish a convention that test vectors are real world examples.

ayne: proposal: capture something from the network and do everything offline

orie: other thing is nice is to regenerate the test vectors without editing anything. every time you do it you would get a new valid one.

wayne: and we would have a clean way to do negative tests too.

joel: more annyone if bots are used.

orie: great point. verification side of this gets very fuzzy if you wanna internalize all the verification part in the test vectors.

wyne: stick on layer 7 on OSI model and implementers can figure it out.

wayne: awesome demo

orie: really cool demo

wayne: can we talk about governance. who should rebase.xyz . if we as going to put resources behind rebase. we want high probability that community owns this. how does DIF solve that?

dan: if we wanna select a WG that already existed, eg.g. credentials. DIF has a framework if you wanna use it.

dan: dif domain is maintained by admins probably.

orie: dif can own more than one domain.

wyc: proposal to have a shared account for cloudflare, rebase domain.

orie: if you need to do something then you should be allowed to do it.

wyc: we want to prevent system from completing messing up after issued millions of VCs. to that point we could have a 4-5 party account and i would propose one rep per org. starting set orie, dan, joel, wayne could be a set of 4 that could have access to the accounts.

orie: eric technically owns all of them today but it should not be one.

wayne: eric could be one of them too but it should not be one.

wayne: ok, we have our governance structure for rebase. we can chime in and compensate eric for buying the domain. spruce owns rebase.org and also want to give that back to the group too.

dan: could we just avoid having the same logo as the keybasse logo.

orie: troll comment is great. talked about splash website. dan prob signed up to do something there.

dan: yes, i was assigned to work to get the website started. waited for the rest of the ppl to agree on what should be on the website. ok, everyone seems to want me to do it.

orie: we need a nice splash webiste. needs to live somewhere, so we can go there and update if needed. logo would be favicon, and be in other places. website usually costs money and usually you have to know what should be on the website before you do it. input to website creation process are logos, brand, fonts ...

dan: is a staic website ok?

wayne: we need vision for the website

orie: all is fine with me, ghpages, static etc.

wayne: it is important to get the branding right and marketing out there. the easier a standard can be adopted, the easier it becomes adopted.

joel: do we want to get to a standard format for the claims we are signing over?

daniel: key types or credential format?

joel: the text that we are claiming, for example the text in the gist on github?

daniel: do sites have different requirements?

joel: yes, but we should still agree to a baseline.

daniel: maybe we have 2 forms, a shortform and a long form?

wayne: i recommend we agree to websites first. then we gather requirements from the real world use cases. we should learn from keybase. the messages should be readable....like keybase. leaning towards putting the DID in the message... seeing the DID there could be good.

joel: next steps, Spruce or Ceramic to PR in the claims / text language.

oliver: we have some language on statements already.... see the draft here: https://hackmd.io/iHHo1rEEQ2WeMzcJBaZexA

joel: lets start with this and do a PR.

wayne: there will be a platform > verification form, pattern.

... rebase can probably handle "private" verification messages... private form will differ from public form.

wayne: eric to transfer domains to a shared account.

joel /wayne: lets push examples to spec.rebase.xyz

wayne: lets host the demo on rebase.xyz.

... issuer should be selectable.

orie: lets get the demo into a github org.

wayne: we would like to contribute our older code.

wayne: we will push stuff we have.

orie: three new repos to be created...

1. corporate website... rebase.xyz (Daniel)
2. metamask <> github demo... demo.rebase.xyz (Joel)
3. tezos dapp issuer... app.rebase.xyz (Wayne)

francis: I'm form knox networks, interested in bank attestations using these schemas.

wayne: lets be careful to get it woring with low assurance use cases first....

francis: yep, interested in both use cases.