# JuiceboxDAO Town Hall Aug 2, 2022

## NFT Rewards Update by @jango

**jango**: We've wrapped up the last few PRs that were ongoing last week, tested and worked, totally good to go. Then on deploying the new contract, it turned out to be slightly too big to deploy. So the last few days we've just been refactoring things into smaller contracts. Things are looking good, and we're getting the tests back to fit in the new structure. But no new logic so it should not be too long before we get the updated contracts on Rinkeby. And then we'll do the versioning for the controllers and terminals that I've been saying. Everything is kind of shifted over a few days because of this refactor that was needed, but I think we're better for it. And we got to make sure we're putting out the thing when it feels finished, and I guess it can actually fit into the blockchain storage spaces. So apart from the tasteful ones, there are some hard constraints that we're usually most constrained by.

I know some people are kind of blocked by this stuff. So I'll continue trying to report it out as much as possible that all happening in that NFT rewards thread that but still sub-threaded in the front end channel, so follow along there for more play-by-play details.

**nicholas**: I saw also there're some [StudioDAO](https://www.studiodao.xyz/) experiments on the Rinkeby, so people can check that out if they're curious.

**kentbot**: Yeah, we've made a lot of Juicebox projects at this point and I'm pretty fast. So yeah, so there's a project that's called the [StudioDAO Backlot](https://rinkeby.juicebox.money/v2/p/4514), and then there is one called [Unlikely Love Stories](https://rinkeby.juicebox.money/v2/p/4515), which is the first film we are going to make. Those are grouped together as the beginning of the network. We're also starting out some governance on Snapshot of the Rinkeby NFTs. That's starting up as well.

**jango**: Thank you for all the feedback thus far also, you've been very helpful and pushing and putting the pressure on the actual transaction etc. The new NFT contract, even on Rinkeby as we're doing, once the front end flips over to whatever updated version, will be like a race to the finish line. I'm not gonna bother for the current health, just making sure all the Rinkeby versions are accounted for. We want to keep that fairly and frequently also, knowing that you all are playing and we're all figuring out how best to use it. I think this one that we're about to put out, though it will blank slate, will probably be the final version before we're good for Mainnet. Meanwhile I'll be playing on Rinkeby this final version then we'll do the updated version and stuff.

**kentbot**: Cool, that's great. The file size on the uploads is still something that I haven't been able to figure out, it seems like it's less than an megabytes right now, is it the limit?

**filipv**: Are you referring to the profile picture for for your project?

**kentbot**: No, for the NFTs.

**jango**: I think that version is not a contract constraint or front end constraint, if any. As far as I know, that constraint's getting fixed this upcoming version. I think @JohnnyD might be waiting on this updated contract which I've been saying, it's just around corner of two days now so.

## Legal Update by @filipv & @tankbottoms

**filipv**: This is related to what @tankbottoms and a few others have been working on.

In general, there have been a lot of people asking for legal advice and things of that nature in Discord. I think the general response we should give, at least for now, is that we're not lawyers and we cannot give people legal advice yet. But we are working on things which will be gone over by lawyers and we'll have a lot of really good documents soon. And the focus on these documents is setting up legal structures that are very easy to deploy. There are a number of legal structures in particular such as Trusts, Unincorporated nonprofits and business structures like LLCs, some of which you can deploy by simply just distributing an operating agreement or guiding principles or something similiar. There is no registration fees, no filing fees, etc. You don't need a register agent, and you can use them to open up bank accounts, you can use them to retain legal services and things like that. So they're like fully fledged legal entities that are very easy to set up.

so yeah, that is the current state of all the legal stuff that's going on right now.

**tankbottoms**: No, I don't need caveat with the Unincorporated Nonprofit, because I think there are around 10 or 15 states that recognize them, but it doesn't mean that they're not recognized entities in other states.

**filipv**: And there will be a number of different legal structures depending on what people's use cases are. If someone is trying to set up something for a pet as an example that @tankbottoms has been bringing up, you can actually set up a trust for a pet in the State of Florida. There're all these weird little jurisdictional things. Those are some questions we're still looking into about what structures will work the best for people, where are different things recognized, where do different things work. But that is a general update of the work that's been going on.

**tankbottoms**: The idea is to say that we're working on it and we want to provide legal resources that even though you can't rely on but you can at least use as a base to start off with. Project creators are making their own decisions, but we are really focusing on these structures where you can search and replace. They still need a lawyer, they still need to get their own counsel, but really taking it from people's perception or people's "Oh, this is a security" or other recognitions, and scope it into something really palatable. It takes the concerns off the table as much as we could.

**filipv**: We cannot provide legal advice to people, but we can curate a lot of stuff and we can work with different service providers to make things really accessible to project creators. I know there have been a lot of questions around it lately, but I'm quite confident that over the next few weeks or next few months, we will be able to get some really really cool stuff happening.

**tankbottoms**: We'll post a tutorial on how to do this later. There is this project called Peace DAO on Juicebox, I went on to the IRS website with the documents of Peace DAO and I got an EIN(Employer Identification Number) number for PeaceDAO. These documents are starting principles in Delaware, you just need to publish it. You don't have to file it and you don't have to pay a filing fee. You don't have to do anything except saying here's what it is. They want to have a fixed amount of tokens, so we defined the amount of tokens as 2²⁵⁶ -1 and we got the EIN number. I have an appointment tomorrow to open bank account with the EIN number. So it gets legit.

**filipv**: It's sick because though we knew that in principle, but actually doing is a whole different thing. It's very exciting, the idea that you can open a bank account for a Juicebox project is pretty cool.

**Zeugh**: Do we have any of that in writing somehow? Legal stuff is very complicated, especially when that's not the law I was grown with, everything is very weird. Reading with time makes it easier.

**filipv**: yeah, so that's what we're working on documenting, putting all of this stuff into writing. If you're interested in looking at the ongoing progress, which is still very early stage, if you're looking at the the stuff that is being put together right now, there's [a branch on GitHub](https://github.com/jbx-protocol/juice-docs-v2/tree/feature/legal-supplement) of the Juicebox docs.

**tankbottoms**: we are trying to like make each of these documents that describe a couple of different angles which includes what the law means or how it works and goals of projects. We try to write the scenarios and then we have documents to support those. When you go to these documents, at the top of the document, you can search for the variables and replace them. we're definitely looking at it from the perspective of how do you include it into the project workflow. Having information that you can put into the project description with some of these documents. Documents in these early stages are depending on the complexity. At the end of the day contracts are agreements between people and so it just depends on how complicated you want to make those agreements.

**kentbot**: StudioDAO is formed as an UNA (Unincorporated Non-profit Association) also, a Nevada UNA, and one of the things that our lawyer wants is, with UNA being an association, when you have people to join the membership, which can definitely be a tokenized membership, it's useful to have these members certify that they agree to a certain agreement. That's something that if we want Juicebox to be able to essentially generate UNA memberships out of the box. It obviously would be super simple, by clicking a certain button and buying this token, new members attest that that they're on this list. That would solve a problem.

**filipv**: Yeah, we can do that right now on juicebox.money with the the pay disclosure.

**tankbottoms**: I mean we can launch the terms of service for the whole site. And exactly as @filipv said. we're envisioning like putting a pay disclosure information or putting a section where project owners can put up something that they want members to assertively agree to.

**kentbot**: Awesome. Yeah, that would definitely make it into an UNA machine.

## IPFS/Pinata gateway discussion

**filipv**: I wanted to have a brief discussion about the IPFS and [Pinata](https://www.pinata.cloud/) Gateway. For those who have not been following the discussion, in short，metadata for Juicebox projects on juicebox.money is currently uploaded through a Pinata Gateway. It seems that the Pinata gateway that we're using for juicebox.money is not a public gateway, because of that people have to upload their metadata directly through juicebox.money. So I want to get some more information on what the pros and cons are for setting that to public and if that's something possible to make public.

**peri**: The trade-off that we have here is that we ultimately end up paying for Pinata based on the volume that goes through our gateway. It's not a crazy expense, so it's definitely possible for us to pay for that to allow anybody to use it however we want. Basically by openning up the gateway, we are providing a PIN service for free to anybody who wants to use it for whatever they want. That might not be ideal. Specifically for storing this type of stuff, a better option is probably going to be creating a second unrestricted gateway.

**Jmill**: Like @Peri said, if we have a dedicated gateway that's open to pin any file, anyone out there can use this for their project and we're paying their expenses, which can run up our quotas. The concern here is if metadata goes from the site to the restricted gateway, in the spirit of openness there will be some level of centralization and the juicebox.money front end is controlling some essential project information.

There's one potential solution where we have this gateway restricted to serve necessary items for the juicebox.money front end, but then in the uploading service the front end could also upload it somewhere that is accessible to anyone who want to use it for a different purpose. That's something we haven't really thought about that, feels like it keeps the best of both worlds of my eyes. If somebody else wants to build on it, they can, the data is there on IPFS for them. But then it replicates in our dedicated gateway for the front end to serve it efficiently and not deal with crazy load times or whatever.

**peri**: Yeah thanks @Jmill, that would be a solid option. I think it's also not out of the question that we actually just we might not need pinning services for this sort of thing. Generally for anybody who doesn't know, information that store on IPFS files that are sort of an IPFS that are uploaded and called garbage collected. If IPFS nodes see that there's a file sitting there that hasn't been queried or hasn't been downloaded in a long time, some arbitrary amount of time which I think might actually not be that long, then it'll get taken down basically. When that happens, the same file can be reuploaded. The way that URLs are gonna work on IPFS is that if you upload the exact same files twice, they'll always be available at the same URL. So basically if that data becomes unavailable, it can just be reuploaded and will be there again at the same URL.

As far as I know, a lot of NFT projects that upload files to IPFS and point to that with the contract token URI. I imagine a lot of them don't actually use IPFS. A common complaint that people have for NFTs is that，projects upload their files to IPFS, but the content might just not be there one day. But he rebuttal for that is, anybody who owns an NFT with the content stored in IPFS, if artwork or whatever for their NFT just disappears one day, they can always just reupload it themselves.

So we could experiment with just avoiding pinning entirely, which is what we use Pinata for. But then we would have to contend with that fact that the stuff eventually will not be available and we might have to have a system for making sure that data can be reuploaded. It could be more of a hassle than it's worth.

**tankbottoms**: I think there's other services that you guys can run. You put on a cloud function to interact with, so you can use unrestrictedly. You can close down the pinning service and only allows you to read stuff that you pinned. If you put it on a cloud function, and then you make your own API key to interact with that cloud function. You can lock it down, but you guys can read all pins. It's still controlled and will not let people to write off the service.

**peri**: That's an interesting idea. If we were gonna do that， would that be too different than just storing the data in a centralized database, if it's gonna be restricted through an authenticated API end point anyway.

**tankbottoms**: yeah, that's a good point. Are you guys on a hosted system already?

**peri**: Yeah, that's true. Let's build a database Y'all, just use a database for you.

**Jmill**: The thing web3 people do to avoid firestore.

**peri**: I think the goal should be to try and optimize as much as possible. If we're putting these smart contracts out in the world. I think the end points that the contract is using to point to the artwork should be as decentralized as possible.

I wonder if we can have an option to create a second Pinata endpoint or second Pinata gateway unrestricted, but only unrestricted to domains for example, and could be limited to a certain set of content. I don't know if that's possible with Pinata or could it be possible with another pinning service.

**filipv**: Yeah, definitely makes sense. But yeah, I think it would be awesome to have that solved because there are a few people who are already deploying projects off juicebox.money through Etherscan or other services because they have run into some trouble with getting metadata working on juicebox.money. So it would be really really awesome to have some type of solution for that in the near future, if possible.

## Hackathon at ETH Safari @Zeugh

**Zeugh**: I think I mentioned it in Town Hall a little while ago about ETH Safari, they are an ETH event in Kenya focusing on being the first big ETH event in Africa. They will have a hackathon in the end. That's going to be made by [Encode](https://www.encode.club/), the same one that made the hackathon in NFT Berlin and Block Split. They are the group that makes hackathons for crypto events.

And well, I was talking to the organizers of the event about Juicebox being part of the event somehow. It might be more interesting to be a hackathon sponsor. I don't know what model you guys think would be most interesting first to bring, but I will have a meeting with the hackathon organization on Friday. Maybe we can make us one of the hackathon sponsors. I think it will be a good idea to talk with them before really going in.

So I am curious to hear your opinions on if that's interesting, and how you think that could be interesting for Juicebox.

**filipv**: Personally, I think hackathons are very interesting and have been pretty successful in recent experience. But I think I would like to get more details on this in specific before making a concrete decision. It's hard with a lack of details, but in general I'm personally interested.

**Zeugh**: Those types of details, I'll probably have them after Friday. I just didn't want to start the talking in that direction if we look at the idea and don't find it a point that Juicebox should be looking towards to, in case to waste time. What I've seen of their hackathons so far, the hackathons are provided by the sponsors and the sponsors get to choose whether they will give prize. Normally we've seen Encode hackathon so far. They have a series of sponsors, each one has their challenges or their criteria however they wanted to put it. They provide support during the hackathon for people that are working on the direction that they're proposing.

**jango**: The people is important. If we have people who are down to be attentive and support the hackathon while it's happening similar to how we did the scaffold-eth one, I think there's a good chance we can do a lot with a little, or a lot with a lot. It's like we're in control of what we get out of. But if it's just money allocation, and then we're gonna hands off or we don't really hold our participation accountable, it doesn't sound too tasteful. I think that it sounds like a cool environment and a cool structure to have some good folks to be working on it. So I'll be curious if it lines up with a period of time where a lot of folks who may be engineering on, the contract side the front end side, because it comes off for a lot of support to help hack alongside them at the time.

**nicholas**: I'm looking into doing more hackathons with [Zora](zora.co) which is interested in collaborating on something, and maybe with [Developer DAO](https://www.developerdao.com/) eventually. I think these could be very cool.

To me the primary criterion should be if the hackathon or potential partners is a suitable place where people who are likely to use Juicebox V2 in interesting projects will be. I wouldn't be so interested in partnering with some large organization like Coinbase, where it's unlikely that the audience will actually enjoy building on top of Juicebox. I'd rather work with a smaller partner who is very inclined to do so.

Ultimately I think there's a general awareness that we get in the hackathons, but the big thing to me is the direct relations with developers. And the prizes don't seem to matter so much, it's more of the event and the camaraderie of the time limit and the goal to ship something before the deadline that seems to motivate people. Although we'll find out more about that in our upcoming feedback form on the scaffold-eth hackathon regardless of whether the proposal passes, we're gonna do a feedback process that @Zom_bae has set up.

So I think the main thing would be less about "oh, it's cool to be at this location!" or whatever, but more about "Do we really genuinely anticipate the people involved will be psyched and relevant folks for building on Juicebox?". I don't see why not but it's worth investigating before committing.

## Two truths and a lie with @Felixander


The correct answer is ... 0xSTVG

***

:bulb: Archives of JuiceboxDAO Town Hall can be found [**here**](https://hackmd.io/@zhape/jbx_town_hall_archive)

###### tags: `JuiceboxDAO Town Hall`