RFC: Planetoids

[Philip Monk]

This is a more specific version of the "off-chain planets" proposal in this thread: https://groups.google.com/a/urbit.org/g/dev/c/xtDXHGfi5Fk/m/vQhB8XyVAQAJ.  Thanks all for the input, it has been extremely useful.

I believe this should be implemented immediately and intend to start working on it soon.  I'm interested in questions, concerns, or suggestions about this proposal.  If you wish to discuss longer term solutions, you may reply to the previous thread or create a new one.

[Ted Blackman]

I'm concerned this design is dangerous.  It solves a (hopefully) short-term problem in a way that could expose the project to long-term risk.  We'd be adding an asset class with an apparently permanent identity — meaning a user could become attached to it — that can be double-spent.  Double-spends are generally considered harmful.

It's easy to say now that the price of planetoids will remain zero, and that these double-spendable assets will only last a little while until we find the next thing.  The truth is, we don't know what the next system will be yet, which means we don't know when it will come online.  So we don't know how long we'll be stuck with planetoids.  The longer they exist, the bigger the risk from the double-spend problem.

If there were some double-spends and we lost the consistency of the PKI state, it would be difficult or impossible to get it back.  If everyone using a planetoid understands its impermanence and is not upset when they lose access to it later, then this wouldn't be catastrophic.

We're at a strange sort of intermediate point right now, where not many people are running stars or selling or giving away planets, but the system is on the cusp of being "real" in a few ways it's never been real before — the UI is approaching consumer-grade, hosting is about to launch, system stability has improved quite a bit, security audit starts soon.

I wouldn't be surprised if planet demand spikes six to twelve months from now, which could very well happen before we've launched a more permanently low-cost PKI solution.  At that point, we'd be asking stars to leave money on the table by giving planetoids away instead of selling them.  As more stars spawn planetoids, more planetoids exist, and the more the planet price rises, the more likely double-spends become, and the higher the potential damage to trust and perceived usability.

Maybe those planetoids don't have the "confirmed on Ethereum" stamp, so caveat emptor.  Are we really so confident in our messaging that we truly believe users will understand not only *all the abstruse crap they already have to understand to get onto Urbit* ("Urbit? Impenetrable" — Ted Nelson), but now also this "transaction confirmation" that costs $50 for some reason?  Otherwise this thing is just a planet-oid, not a … what was it? a moon?  What is a pier, again?  Whatever, I know people are into this, so I'll buy one for $10, but $60 is too much.

I'm not categorically opposed to a temporary bandaid to get the network through this rough patch in a way that we don't expect to scale well a year or two from now.  My concern is that planetoids introduce several new failure modes that would be impossible (or at least deliberately mitigated) in any blockchain-like system, and that the risk of those failure modes can reasonably be expected to worsen over time.

We do have to do something to get people using Urbit while the Eth prices are high.  I suggest the we do the most obvious thing, which also doesn't require writing code: let them spawn a comet.  We want people to be able to get onto the network for free, with a temporary address until they're ready to pony up (no ponies were harmed in the writing of this email) the cash for a planet.

The downside of encouraging comets is that it doesn't create a strong emotional binding between user and address.  They'd have to buy a planet for that.  Then again, we're hoping the strong emotional binding does not occur with planetoids — we really want them to formally buy the planet if they start to feel that way, but if Ethereum prices remain high, there's a good chance a large percentage of them just won't.

We could also do quite a bit to make comets a more appealing option.  Right now, comets take a fairly long time to spawn.  This could be remedied easily by adding more stars to the comet sponsor list, which is just a text file (and the stars have to be running).  Once the userspace data import/export scripts land, that will also help smooth over the switch from comet to planet somewhat.

The other problem with comets right now is that the comet has to talk to you before you can talk to it.  We should probably add a pathway, maybe in :groups, where the group owner shares all comet members' self-attestations with the group members, who store them in Jael.  That way you could start a DM with a comet if you're in any of the same groups as it.

Comets aren't a perfect solution.  But I'm not convinced the long-term risk of planetoids outweigh their short-term convenience.

—

~rovnys-ricfer

https://urbit.org

[Matilde Park]

Don’t we have a process-oriented solution by just prespawning planets during low gas periods to master ticketed wallets and hand new users the wallet directly? We could do some FE work for this process for people with invites, and we can adjust what we tell providers. This seems better than adding complexity and multiple types of authentication that compromises the mission; or otherwise relying wholeheartedly on comets instead. It also is just a Bridge product problem.

—
~haddef-sigwen
https://urbit.org

[Jared Tobin]

On Tue, Sep 15, 2020 at 12:37:28PM -0400, Matilde Park wrote:
> Don’t we have a process-oriented solution by just prespawning planets
> during low gas periods to master ticketed wallets and hand new users
> the wallet directly?
>

> > On Sep 15, 2020, at 12:17 PM, Ted Blackman <t...@tlon.io> wrote:
> > We do have to do something to get people using Urbit while the Eth
> > prices are high. I suggest the we do the most obvious thing, which
> > also doesn't require writing code: let them spawn a comet. We want
> > people to be able to get onto the network for free, with a temporary
> > address until they're ready to pony up (no ponies were harmed in the
> > writing of this email) the cash for a planet.
> >

> > [..]

> >
> > Comets aren't a perfect solution. But I'm not convinced the
> > long-term risk of planetoids outweigh their short-term convenience.

FWIW, I think these are very satisfactory solutions. In particular,
with respect to the planetoid "buy time" proposition:

> This is proposed with the expectation of and to buy time for a later
> scalable solution which preserves the sovereignty characteristics of
> existing Azimuth.

A mix of increased comet usage/encouragement/support and opportunistic
pre-spawning of planets seems to accomplish the same thing, and uses
only simple, existing mechanisms.

--
~nidsut-tomdun
https://urbit.org

[Galen Wolfe-Pauly]

The planetoid proposal came from the thinking that we (Tlon) really want to be able to onboard people as a 'provider' (https://urbit.org/blog/providers/). To be super-specific: our hosting service is coming along nicely, and as we roll it out we want to make onboarding as easy as possible. To do that right now we'd need to spend thousands (potentially hundreds of thousands) of dollars on gas costs. So, my thinking was: how can we onboard people during this interim period where spawning on-chain planets isn't workable? And can we come up with something that would allow other providers (see Christopher King's recent thread) to do the same? 

It looks likely that we'll need another solution for planets in the long term, and we've started to research what the right solution is. But for now, Urbit is ready for more users to join the network. To slow down our progress here, I think, would be bad for the network as a whole.

My original thought was actually to use moons, but comets go after a similar approach: use something that already exists in the system. The problem is, changing names is pretty painful. If someone starts with a super-long, not-memorable, not-pronounceable name that's pretty ugly. Also, what does the upgrade path look like? Do I lose everything on my comet when I switch to a planet? How do I force others to change their references? 

In talking to another galaxy holder this morning I came up with a modification to the planetoid proposal that might make it more approachable:

Why not only allow stars to spawn planetoids with some kind of on-chain attestation from a different galaxy? So, if ~samzod wants to spawn planetoids they need to have an attestation from someone other than ~zod that they're an 'approved planetoid source'. Perhaps it's even better if these attestations are signed by multiple parties or even some minimum boundary of 8 — I'm not exactly sure.

We don't want people selling planetoids then double-spending planets. But we do want planetoids to exist for trusted parties that are trying to encourage network growth and adoption. If a galaxy (or group of galaxies, or some combination I haven't thought of — feel free to suggest) attests to the trustworthiness of the star, I think we should be inclined to trust them during this interim period. 

Anyway, happy to hear thoughts or suggestions on whether this seems workable. I think the upgrade path from a comet or a moon looks pretty tough, but I'd happily hear thoughts on that as well.

A few other notes:

- It's critically important that the holder of a planetoid can always upgrade to a real planet by simply taking their planet to the chain and paying the gas cost

- It's also really important that planetoids are distinguished somehow in the UI so it's clear that the planetoid is not yet fully sovereign. This implies that the 'upgrade path' will need to be easy to understand in Bridge.

[Matilde Park]

> It looks likely that we'll need another solution for planets in the long term, and we've started to research what the right solution is. But for now, Urbit is ready for more users to join the network. To slow down our progress here, I think, would be bad for the network as a whole.

I’m sure Ted will opine, but his point was that this solution would make it worse for the network as a whole later given the same mass onboarding predicate.

> The problem is, changing names is pretty painful. If someone starts with a super-long, not-memorable, not-pronounceable name that's pretty ugly. Also, what does the upgrade path look like? Do I lose everything on my comet when I switch to a planet? How do I force others to change their references?

This is something we’ve thought about and are sorta close to solving in userspace, though. The idea of people starting with a comet and upgrading to a planet *can feel really good*. And as a problem it’s probably an easier thing to solve than the RFC here — easiest for a hosting provider, but agnostically, it could be a front-end “swap in your comet’s data” process. Booting a ship with a predecessor ship’s stuff seems long-term thinking, seems Urbit.

Ultimately subscriptions might be the harder part; but importing and exporting are projects in progress and we’re going to have to be able to migrate nearly a whole era’s data, aren’t we? Breaches are n > 0.

—
~haddef-sigwen
https://urbit.org

[Galen Wolfe-Pauly]

Here’s the case I’m concerned with:

If you were a comet and sent messages to a channel we’re both in, how do I know you upgraded and what do I rewrite the messages to? 

It’s architecturally really ugly. The system treats names as permanent addresses because it’s clear and simple. Not sure we want to push this problem into user space or kernel space. 

--

Sent from my phone

[Anthony Arroyo]

Upgradeable comets is a great feature, without doubt. And I'd love to not let this crisis go to waste.

I wonder if we couldn't use Azimuth claims for this. Could I not, once I've grown up, put a claim on the blockchain that says I used to be such and such a comet? You have jael ingest that state and then ... do something.

—

~poldec-tonteg

http://urbit.org

[Ted Blackman]

I think it would be quite complex to have the rest of Urbit automatically understand the upgrade from comet to planet, especially in a way that's baked deeply into the system.  Re-sending messages is a bit of a red herring, though.  I think it would be up to the new planet to import the data from their old comet.  This should include old DMs, notebook comments, etc.  Other people shouldn't have to send it the same data again.

If lots of people are switching from comets to planets, it could be confusing to keep track of who's who, and if someone knew me as a comet I'd have to convince them I'm now this new planet.

My first thought for this was (as Anthony just independently suggested as I write this) that a planet could attest to ownership of a comet on-chain using the Claims contract by including the planet address signed by the comet's key.  I was thinking then the galaxies could distribute that information and some kind of notification could be sent to the network, which a UI could use to somehow link the old and new identities.

There are a couple problems with that, though.  One is that it requires an on-chain attestation, which might be expensive.  Another is that multiple planets could potentially claim the same comet (I suppose it would be possible to add a uniqueness constraint to the contract, but I don't have a great sense of the complexity required for that).

The other problem is that if some app wants to use this information, it can't just use ship-name anymore — it has to use ship-name *and* this extra metadata field, and maybe also other pieces of state (did we have a chat with the old comet's address?).  I'd rather not let this kind of conceptual overhead into the system.

This second problem would apply even to an off-chain, intra-Urbit attestation of comet ownership, whose Hoon would probably look pretty similar.

I'm not sure how necessary it is to automate this, though.  We do have nicknames already.  If after ascension to planethood, I'm concerned people might not know who I am, I could include my old comet name in my nickname for a while.

—

~rovnys-ricfer

https://urbit.org

On Tue, Sep 15, 2020 at 4:12 PM, Galen Wolfe-Pauly <ga...@tlon.io> wrote:

Here’s the case I’m concerned with:

If you were a comet and sent messages to a channel we’re both in, how do I know you upgraded and what do I rewrite the messages to? 

It’s architecturally really ugly. The system treats names as permanent addresses because it’s clear and simple. Not sure we want to push this problem into user space or kernel space. 

[Anthony Arroyo]

> I'm not sure how necessary it is to automate this, though.  We do have nicknames already.  If after ascension to planethood, I'm concerned people might not know who I am, I could include my old comet name in my nickname for a while.

A solution after my own heart, assuming we have rock-solid export/import for at least Landscape (mebbe even a pattern that 3rd party devs can use).

—

~poldec-tonteg

http://urbit.org

On Tue, Sep 15, 2020 at 4:11 PM Ted Blackman <t...@tlon.io> wrote:

I think it would be quite complex to have the rest of Urbit automatically understand the upgrade from comet to planet, especially in a way that's baked deeply into the system.  Re-sending messages is a bit of a red herring, though.  I think it would be up to the new planet to import the data from their old comet.  This should include old DMs, notebook comments, etc.  Other people shouldn't have to send it the same data again.

If lots of people are switching from comets to planets, it could be confusing to keep track of who's who, and if someone knew me as a comet I'd have to convince them I'm now this new planet.

My first thought for this was (as Anthony just independently suggested as I write this) that a planet could attest to ownership of a comet on-chain using the Claims contract by including the planet address signed by the comet's key.  I was thinking then the galaxies could distribute that information and some kind of notification could be sent to the network, which a UI could use to somehow link the old and new identities.

There are a couple problems with that, though.  One is that it requires an on-chain attestation, which might be expensive.  Another is that multiple planets could potentially claim the same comet (I suppose it would be possible to add a uniqueness constraint to the contract, but I don't have a great sense of the complexity required for that).

The other problem is that if some app wants to use this information, it can't just use ship-name anymore — it has to use ship-name *and* this extra metadata field, and maybe also other pieces of state (did we have a chat with the old comet's address?).  I'd rather not let this kind of conceptual overhead into the system.

This second problem would apply even to an off-chain, intra-Urbit attestation of comet ownership, whose Hoon would probably look pretty similar.

I'm not sure how necessary it is to automate this, though.  We do have nicknames already.  If after ascension to planethood, I'm concerned people might not know who I am, I could include my old comet name in my nickname for a while.

—

~rovnys-ricfer

https://urbit.org

On Tue, Sep 15, 2020 at 4:12 PM, Galen Wolfe-Pauly <ga...@tlon.io> wrote:

Here’s the case I’m concerned with:

If you were a comet and sent messages to a channel we’re both in, how do I know you upgraded and what do I rewrite the messages to? 

It’s architecturally really ugly. The system treats names as permanent addresses because it’s clear and simple. Not sure we want to push this problem into user space or kernel space. 

[Philip Monk]

I think the biggest takeaway is that we shouldn't talk about double-spendable things as though they're owned.  They're not, and any scheme to make them ownable *must* solve the double spend problem, and the only known way to do that trustlessly is proof of work (and *maybe* proof of stake).  If planetoids are issued off-chain, then they're double-spendable, which means they aren't really "issued".  Any attempt to create a sort of "soft" ownership invite trouble.

We've framed planetoids incorrectly.  You can't own a planetoid, you can only rent one.  Perhaps giving them a different name lends to the illusion that they exist in themselves, when they're only a rental agreement.  I'll try calling them "rental planets" for now.

Servicing a rental planet is an ongoing obligation (to keep the star online and not rent that planet to someone else), so it should be paid for on an ongoing basis.  Paying up front in exchange for an ongoing obligation is unsound.

I've attached an updated proposal which describes renting planets instead of owning planetoids.

On Tue, Sep 15, 2020 at 2:15 PM, Anthony Arroyo <ant...@tlon.io> wrote:

> I'm not sure how necessary it is to automate this, though.  We do have nicknames already.  If after ascension to planethood, I'm concerned people might not know who I am, I could include my old comet name in my nickname for a while.

A solution after my own heart, assuming we have rock-solid export/import for at least Landscape (mebbe even a pattern that 3rd party devs can use).

—

~poldec-tonteg

http://urbit.org

On Tue, Sep 15, 2020 at 4:11 PM Ted Blackman <ted@tlon.io> wrote:

I think it would be quite complex to have the rest of Urbit automatically understand the upgrade from comet to planet, especially in a way that's baked deeply into the system.  Re-sending messages is a bit of a red herring, though.  I think it would be up to the new planet to import the data from their old comet.  This should include old DMs, notebook comments, etc.  Other people shouldn't have to send it the same data again.

If lots of people are switching from comets to planets, it could be confusing to keep track of who's who, and if someone knew me as a comet I'd have to convince them I'm now this new planet.

My first thought for this was (as Anthony just independently suggested as I write this) that a planet could attest to ownership of a comet on-chain using the Claims contract by including the planet address signed by the comet's key.  I was thinking then the galaxies could distribute that information and some kind of notification could be sent to the network, which a UI could use to somehow link the old and new identities.

There are a couple problems with that, though.  One is that it requires an on-chain attestation, which might be expensive.  Another is that multiple planets could potentially claim the same comet (I suppose it would be possible to add a uniqueness constraint to the contract, but I don't have a great sense of the complexity required for that).

The other problem is that if some app wants to use this information, it can't just use ship-name anymore — it has to use ship-name *and* this extra metadata field, and maybe also other pieces of state (did we have a chat with the old comet's address?).  I'd rather not let this kind of conceptual overhead into the system.

This second problem would apply even to an off-chain, intra-Urbit attestation of comet ownership, whose Hoon would probably look pretty similar.

I'm not sure how necessary it is to automate this, though.  We do have nicknames already.  If after ascension to planethood, I'm concerned people might not know who I am, I could include my old comet name in my nickname for a while.

—

~rovnys-ricfer

https://urbit.org

On Tue, Sep 15, 2020 at 4:12 PM, Galen Wolfe-Pauly <galen@tlon.io> wrote:

Here’s the case I’m concerned with:

If you were a comet and sent messages to a channel we’re both in, how do I know you upgraded and what do I rewrite the messages to? 

It’s architecturally really ugly. The system treats names as permanent addresses because it’s clear and simple. Not sure we want to push this problem into user space or kernel space. 

[~forfel-norfel]

What about just enabling use of Ethereum Classic or one of the scaling systems being built for Ethereum? People who really value the security can pay whatever the cost is to use Ethereum, and people who aren't as concerned can use the cheaper alternative. Block transactions from any less secure source for anything that's already been spawned with Ethereum.

It seems like this has the benefit of not needing to modify or abuse Urbit's design, which is a serious concern with the other options.

[Christopher King]

Possibly out of my element here, but isn't Ethereum Classic an entirely different chain now? How could both be used?

--
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@urbit.org.

[Rob Myers]

Ethereum Classic is currently undergoing a series of 51% attacks. This means that planet transfers might revert on it hours after they initially appear to succeed.

A sidechain like Matic would work if the mainnet contracts could be adapted to use it but this would introduce some degree of complexity and risk.

High gas prices may be an economic opportunity - to make planets worth the transaction fees - rather than a technical problem though.

- Rob.

[~forfel-norfel]

Yes, it's completely separate, but in theory it could be used as an alternative source for PKI updates provided that Urbit includes some additional logic to handle having multiple sources and the potential for conflicts.

I don't know enough about the current contract, but I assume there are a few possibilities here. For example, if the majority of the cost to spawn planets is from the PKI stuff and not just creation and transfer of the token, the transfer could simply include a message that all of the expected data will be somewhere else.

If there's some limitation with how the contract works, stars could sign a message unrelated to anything with the contract saying that all future planets will be spawned with Eth Classic. Obviously this wouldn't prevent people from spawning the planets on both chains, but Urbit can include logic to know which to believe. Any consensus just needs to be within Urbit and the Urbit network. What Eth or Eth Classic believe is only relevant then if you're trusting them for ownership info without checking Urbit, and the solution to that could just be adding a feature to Bridge to ensure people don't buy a planet on the wrong chain.

That last option is more of a worst case, very primitive, out of band solution. I'm guessing something a lot better is possible, given all of the wacky features Ethereum is supposed to offer and recent developments like cross chain transactions.

51% attacks shouldn't be much of a concern as long as the ownership and key data is eventually consistent. Double spending has very limited potential for abuse with individual planets. 

Anyway, my belief is that a weird blockchain mess that still enables easy, affordable, and permanent planet ownership is preferable to something that compromises the idea of people using these memorable identities that they're attached to and have complete control of. Also, the goal is to eventually not depend on Ethereum or any external source, so enabling use of alternative sources seems like a step towards having the PKI entirely within Urbit.

[Vitor Py]

Sorry, I'm new to this community, so please let me know if I'm not making any sense.

A common scaling solution into the NFT space right now is using xDai (or other POA/POS EVM-compatible sidechain) and a token bridge. See: https://github.com/poanetwork/tokenbridge So in theory, a secondary market for planets could be created in xDai and transfer transactions can be batched by the bridge. Unless a new contract is deployed per planet, gas consumption should be limited to storage access, computation, storage access. I'm happy to help POC this concept if someone is interested.

Cheers and sorry if I'm missing something,

Vitor.

[Galen Wolfe-Pauly]

Victor (new voices are always welcome!) and ~forfel-norfel: perhaps these are good solutions. We've discussed xdai a bit, I'm pretty skeptical of Ethereum Classic but who knows, maybe I can be convinced. 

The main thing is, I think it'll be easiest if we keep it to one-proposal-per-thread. Admittedly, this wasn't particularly well organized from the outset. This is probably our first time having to make a significant decision that the galaxies will also likely have to vote on. 

To do this efficiently, we need a somewhat more organized process. I'll propose one in a separate thread shortly. For now, let's continue discussing the planetoids proposal here. I'm generally amenable to it if we can find some way to make planetoids truly understood as a 'demo mode' thing. But it may be that the risks outweigh the benefits, and it warrants further discussion. I'd be especially interested in hearing from those who either operate planet marketplaces or were planning to offer hosting / provider services.

[Christopher King]

Finally had the time to catch up on this closely.

While I'm an engineer, I generally think about Urbit in customer-centric business terms, especially what can get us to the point that the average internet user can and will want to use the platform. I (and most of us here) have a personal stake in making this the case in order to increase the value of the stars I own.

First, if I understand it correctly, the initial planetoid proposal is kind of a slap in the face to the stars. How often are people really going to update from a planetoid to a real planet? Would the average person care enough about digital sovereignty to pay extra for it, when they could just get a non-sovereign ship instead? Probably not, considering how willing people currently are to fork over their data to MEGACORP. So this ends up drastically diluting the value of stars and galaxies. If the owners of the latter don't see a business reason to push their services, that will be more harmful to the network long-term than some initial friction to get online.

Second, unless there are some unknown costs Tlon is currently eating for every planet spawned anywhere, I'm not sure where the hundreds of thousands of dollars quote Galen mentioned comes from. Sure, you can spend that if you want to spawn a massive pool of planets and draw from them as needed. But you don't have to do that. You can spawn them as you go. Yes, as things stand this will probably cost way more than you're willing to charge for a planet up front. However, a hosting model is a great way to get around this. I am confident that the business model of my recently-released hosting service is sound, given the value of the recurring revenue as opposed to single purchases. (This is where the real value of Urbit will come from, in my opinion.) Really, this isn't so different from the planet-rental proposal, and it's feasible as Urbit currently stands.

Third, an expensive planet, while bad, is not necessarily terrible. It will make the owner feel like they have a stake in it, and it may have more value for them psychologically. I always think about Joe Rogan saying that the worst audiences to do stand-up for are the ones who got free tickets. There is a fine line to walk with planet prices, but there is more nuance to it than has been discussed.

Personally, I'll be pretty pissed if my recent efforts to set up a hosting service get blown away by some big change in how planets work. I have created my platform at considerable financial, professional, and personal cost. (Saying "Urbit" around my wife is like saying "Yarvin" at a Google struggle session.) I do hope any solution settled on will be backward compatible, so to speak.

[Galen Wolfe-Pauly]

(It takes me a few days to find time to respond to these threads. Sorry!)

Good responses. Responding to Christopher's points in order:

First, if I understand it correctly, the initial planetoid proposal is kind of a slap in the face to the stars. How often are people really going to update from a planetoid to a real planet? Would the average person care enough about digital sovereignty to pay extra for it, when they could just get a non-sovereign ship instead?

 

Assuming, as a provider, I'm going to both (a) pay to run servers and (b) charge people to use my service, I want to keep my costs as low as possible. If part of my cost is paying $30 - $100 to register each planet that pretty severely impacts my margins. I could potentially pass that cost along to the user, but how exactly? By checking the gas cost, converting it to USD, then having my prices constantly fluctuate? Obviously that's a bad idea: it'd be best to be able to offer a flat rate of some kind. If I'm charging someone $20 / month for planet hosting it's going to take me up to five months to recoup the gas costs. Sure, maybe Urbit is a luxury good — but is it now $500 a year for planet hosting? Possible, but limits the number of people we can bring on to the network.

The planetoids proposal is designed to make it *easier* for star owners to make money on recurring revenue. Skip the gas cost, get someone up and running (and paying for hosting) as quickly as possible. Remember: a planetoid isn't an asset. It should never be described as one. It shouldn't be sold. You're *selling* someone hosting, and there should be some simple way to upgrade (or 'exit') to actual planet ownership whenever.

Planetoids are designed to keep a provider's overhead so low they can focus on quality of user experience — which is the whole value prop of a provider to begin with.

Second, unless there are some unknown costs Tlon is currently eating for every planet spawned anywhere, I'm not sure where the hundreds of thousands of 

dollars quote Galen mentioned comes from.

Yes, we run a gas tank connected to the hosted version of Bridge that funds transactions up to a certain limit. For the most part, all transactions are over that limit right now which means it's impossible to spawn a planet for free. That figure is based on looking at the road ahead: if we want to onboard a few thousand people at $100 a planet, well, it adds up. If you do it 'as you go'  (as you suggest) it's potentially even more painful. Gas prices could easily get worse. You're gambling your margins on what's going on with DeFi. Seems risky. 

Not sure I understood your final point about how 'planet rental' already exists. 

Third, an expensive planet, while bad, is not necessarily terrible.

Yeah, I generally agree with this. The interesting thing is, I'm not sure that was true the first day I was using Urbit. The problem with every account that you have, and probably even your email account, is that it's not portable. You can't keep it. You can't register it on chain and go elsewhere. It's one thing to have to pay $50 for a gmail account. It's another to pay $50 to move your gmail address to protonmail without any issue.

~ravmel-ropdyl was given to me by Tlon (thanks). I'm not sure I would have paid for it right away. But I'd certainly pay $100 to keep it now if I had to.

I have created my platform at considerable financial, professional, and personal cost. 

For what it's worth: we want you to succeed. I'm curious if you can see the simple bottom-line benefit of issuing people planetoids to begin with. I think this whole decision is about weighing that benefit (which makes it easy for providers to help onboard people and grow the network) against the long-term issues of having these rental names kicking around. 

[~forfel-norfel]

What happens when a successful host starts making it inconvenient for planetoids to leave? What happens when that host starts leveraging their trapped user base to dictate how the entire network should work? If the goal is to recreate Gmail, Urbit's design is unnecessarily complicated.

[Galen Wolfe-Pauly]

What happens when a successful host starts making it inconvenient for planetoids to leave?

 

A planetoid, as designed, can register themselves on-chain whenever they like and then escape to a different star. The only thing the host / issuer can do is deactivate the planetoid.

What happens when that host starts leveraging their trapped user base to dictate how the entire network should work?

I think you'll need to flesh that out a bit for me to understand how it's practically possible. It'll be quite some time before anyone has that kind of weight to throw around. Any long-term solution should quietly register / upgrade planetoids.

If the goal is to recreate Gmail, Urbit's design is unnecessarily complicated.

Urbit's goal is obviously not to recreate gmail. 

[Gus MacAulay]

> A planetoid, as designed, can register themselves on-chain whenever they like and then escape to a different star. The only thing the host / issuer can do is deactivate the planetoid.

This is the bit that is still a bit unclear (to me at least).  In the planetoid model, who owns the planet? I intuitively thought it would be the star, and the planetoid (tenant) could only buy it's way to sovereign planethood with consent of the sponsoring star (landlord), but this sounds like the ownership is contested/contestable and a matter of who shoots first (deactivate vs escape).  Perhaps this is ok if the starlords understand the risks and price planetoids accordingly!?

Gus

[~forfel-norfel]

(Sorry for the duplicate emails Galen. Email is hard.)

The planetoid explanation seems to imply that users would need the star to cooperate when they want to convert to a full planet. Is that not the case?

Most people aren't going to care about having ownership of anything on Urbit at this point or possibly ever. The cost of gas is irrelevant to them. They'll only care about having ownership once it offers a tangible benefit to them, which is likely to be the moment they decide they want to leave their host. If these people have had planets all along, they're fine. If they have planetoids and their host can prevent them from leaving, Urbit has completely failed at one of its main goals.

What prevents a host from deactivating a planetoid, registering that planet on Azimuth but maintaining ownership of it, and then supplying the network keys to the user as though it's some complicated maintenance thing they were forced to do or even an upgrade? Most users aren't going to understand any of that or care.

Anything that depends on a network effect is typically stuck with whatever the defaults were at the time of wide adoption. It's why IPv6 is never going to happen, why game console add-ons and similar upgrades for other platforms are almost always poorly supported, and why there's a need for Urbit in the first place. The internet's design is fully P2P, but expensive IP addresses forced most users to only be able to function well in a client role, and now we have Google controlling email, web standards, the most popular computer platform, online video, and a huge percentage of user data.

I really hate Google, yet I'm still using a Gmail address I've had since 2004 because switching would be too painful, and I even picked Gmail again for this address because it's so fucking easy. I know more about this issue and the problems it creates than 99% of the people that we hope to have on Urbit someday, and I still picked the bad option.

Any default option would ideally be flawless, but predicting the future is hard, so Urbit is inevitably going to have weaknesses in 20 years that nobody could imagine today. What is realistic though is avoiding flaws we already know exist, and we know exactly how terrible the result is when people don't have full control over their online identities. Depending on hosts to do the right thing with planet registrations and not grow too big would be a huge mistake. Claiming a planet that you expect will be yours forever is so important to solving the problems with the current system that it needs to be a core part of Urbit culture. Any default that doesn't guarantee permanent ownership is unacceptable, and just a pointless reimagining of the past 30 years.

[Christopher King]

Galen: thank you for the thoughtful responses to my comments. It is clear to me from your statements that I may be misunderstanding important aspects of the planetoid proposal, so I'm going to step back from further comment there until my understanding improves.

I do think ~forfel-norfel's concerns are well-founded. We really, really don't want to just morph into what we're trying to replace. I think that's a real hazard among some of the changes being discussed.

[Galen Wolfe-Pauly]

As per my proposed process in the other thread I had intended to close the loop here a week ago. Sorry to be late!

After plenty of internal discussion and some informal on-urbit discussion with community members, I think that planetoids / rental planets are ultimately not needed. 

The simplest reason for this is the cost / benefit of implementing this solution. The engineering cost to implement planetoids may simply be more than the cost to pre-spawn planets. 

We've started pre-spawning planets at off-peak gas times and can seem to be able to get them through at about 50gwei if we're not in a hurry. Pre-spawning isn't ideal from an ownership standpoint, since we're handing over a master ticket rather than having someone generate their own keys. But, like rental planets, people can always re-ticket if they feel so inclined and pay their own gas fees. 

(To be clear, this approach is to serve Tlon's interest in onboarding new users into our hosting service. Gas costs are still a challenge for anyone buying a planet through urbit.live, OpenSea or similar.)

If we see the network start to grow quickly before our long-term solutions start to get implemented we may want to reopen this discussion. I still think this is a reasonable proposal — but let's table it for now and focus on discussing what our longer term options are.

On that front, both Philip and I (but, let's be honest, mostly Philip) have been researching all of our other possible solutions. In the next few weeks we'll try to lay them out here and dig in to Ted's proposal for a proof-of-authority approach.

[Christopher King]

Where do things stand with the above discussions now? The extreme gas prices seem to be a problem that isn't going away, unfortunately.

[Galen Wolfe-Pauly]

> In the next few weeks we'll try to lay them out here and dig in to Ted's proposal for a proof-of-authority approach.

Whoops—sorry for not sticking to that commitment. 

I'll give a very off-the-cuff update here, and perhaps Philip can chime in since he's taken this up as his primary area of work. So, briefly:

- While self-hosted, proof of authority (ish) solutions are interesting because of their lack of dependencies, it seems overly ambitious to implement one in short-order. We've continued to think through how an approach like this might work, but we're not actively pursuing it. 

- Our research on possible layer 2 solutions was worthwhile, and Philip is now going through each of the candidates and building out prototypes to see how they fare. After doing that, we intend to pick one and try to move forward. Better not to comment on timing at this stage, but we're moving forward.

It's true that the gas prices are a very real and painful problem. We have continued to pre-spawn planets, but it's not enough to keep up with demand. This is probably our biggest scaling problem and we're working on it.

[Christopher King]

Thanks for the update, Galen. I'm glad it's still an active area of research. It may be worth including brief updates on the matter in future Tlon newsletter emails in the future.

[Philip Monk]

For those interested in specifics, the three options under consideration are Starkware's Cairo system (ZK rollup, STARKs), Matter Labs's zkSync/Zinc (ZK rollup, SNARKs), and Optimism's OVM (Optimistic Rollup).

I've writtten a minimal prototype in Cairo (https://github.com/urbit/azimuth-cairo) and I've read the Zinc docs.  I hope to write something in Zinc soon and maybe even deploy it to the Rinkeby testnet to play around with in the wild.  Then Optimism will be the next thing to evaluate.

On Fri, Jan 22, 2021 at 11:14 AM, Christopher King <ch...@cking.me> wrote:

Thanks for the update, Galen. I'm glad it's still an active area of research. It may be worth including brief updates on the matter in future Tlon newsletter emails in the future.

On Fri, Jan 22, 2021 at 2:10 PM Galen Wolfe-Pauly <galen@tlon.io> wrote:

> In the next few weeks we'll try to lay them out here and dig in to Ted's proposal for a proof-of-authority approach.

Whoops—sorry for not sticking to that commitment. 

I'll give a very off-the-cuff update here, and perhaps Philip can chime in since he's taken this up as his primary area of work. So, briefly:

- While self-hosted, proof of authority (ish) solutions are interesting because of their lack of dependencies, it seems overly ambitious to implement one in short-order. We've continued to think through how an approach like this might work, but we're not actively pursuing it. 

- Our research on possible layer 2 solutions was worthwhile, and Philip is now going through each of the candidates and building out prototypes to see how they fare. After doing that, we intend to pick one and try to move forward. Better not to comment on timing at this stage, but we're moving forward.

It's true that the gas prices are a very real and painful problem. We have continued to pre-spawn planets, but it's not enough to keep up with demand. This is probably our biggest scaling problem and we're working on it.

[Christopher King]

This ought to be Manhattan Project-ified. It's the largest current obstacle to network growth. Is there appetite for bounty proposals on this?

On Fri, Jan 22, 2021 at 2:27 PM Philip Monk <phi...@tlon.io> wrote:

For those interested in specifics, the three options under consideration are Starkware's Cairo system (ZK rollup, STARKs), Matter Labs's zkSync/Zinc (ZK rollup, SNARKs), and Optimism's OVM (Optimistic Rollup).

I've writtten a minimal prototype in Cairo (https://github.com/urbit/azimuth-cairo) and I've read the Zinc docs.  I hope to write something in Zinc soon and maybe even deploy it to the Rinkeby testnet to play around with in the wild.  Then Optimism will be the next thing to evaluate.

On Fri, Jan 22, 2021 at 11:14 AM, Christopher King <ch...@cking.me> wrote:

Thanks for the update, Galen. I'm glad it's still an active area of research. It may be worth including brief updates on the matter in future Tlon newsletter emails in the future.

On Fri, Jan 22, 2021 at 2:10 PM Galen Wolfe-Pauly <ga...@tlon.io> wrote:

> In the next few weeks we'll try to lay them out here and dig in to Ted's proposal for a proof-of-authority approach.

Whoops—sorry for not sticking to that commitment. 

I'll give a very off-the-cuff update here, and perhaps Philip can chime in since he's taken this up as his primary area of work. So, briefly:

- While self-hosted, proof of authority (ish) solutions are interesting because of their lack of dependencies, it seems overly ambitious to implement one in short-order. We've continued to think through how an approach like this might work, but we're not actively pursuing it. 

- Our research on possible layer 2 solutions was worthwhile, and Philip is now going through each of the candidates and building out prototypes to see how they fare. After doing that, we intend to pick one and try to move forward. Better not to comment on timing at this stage, but we're moving forward.

It's true that the gas prices are a very real and painful problem. We have continued to pre-spawn planets, but it's not enough to keep up with demand. This is probably our biggest scaling problem and we're working on it.

[Philip Monk]

I would love to Manhattan this project, and we absolutely would be willing to pay stars to speed it up. I'm all ears for ways to speed up this project.

Frustratingly, we haven't quite decided the outline of the solution - there's still three possible solutions. I don't know how to parallelize that since one person needs a practical understanding of each option (and be immersed in Urbit) to make that recommendation.

I hope to decide the technical solution in the next two or three weeks. Then, we can make a plan for implementing and migrating, and that could definitely have bounty-able tasks.

[Charlie Cummings]

Has there been any thought on bringing Azimuth ownership in-house? Have all the galaxy subscribe to the ethereum data so that external smart contracts still work, but have extra off-chain data "overlayed" on it and be the final source of truth, so that for PKI you ask a galaxy (or several) instead of eth-spider? Then having an Ethereum null address you transfer all your planets to to "burn" them, and allow the galaxies to get signed transactions via Urbit moves from the stars to give out the burned planets off-chain.

[Galen Wolfe-Pauly]

This strikes me as pretty similar to the planetoids proposal above, although that proposal doesn't involve burning planets. 

I think much of the discussion about the tradeoffs surrounding solutions like this were discussed. Then, iirc, we tried to create separate threads for each proposal (of which this is one). If you want to flesh your thinking out a bit, I'd suggest starting a new thread so we can dig in on the specifics. But it's probably worth reading the mailing list archives from the tail end of 2020 if you haven't already.

[Juanjo Presa]

What about Gluon Layer 2 based solutions? People behind LeverJ exchange have it working for some time. Maybe there is not hype about Gluon tech but it works since today.

[Christopher King]

Philip, please keep me updated. I'd like to propose a bounty on this when parallelization is possible. I have a vested interest in solving this.

[Mike Gogulski]

I might be persuaded to toss a star into the bounty pool myself.

[Mike Gogulski]

Worth mentioning: Dapper FLOW is a smart contract blockchain platform specifically designed for NFTs, created by the CryptoKitties folks. They had an IEO on CoinList in September and the token just started trading (though IEO buyers have a 1-year lockup).

https://www.onflow.org/primer

[Christopher King]

Philip, did you decide on an approach?

[Philip Monk]

We're close, we have it basically narrowed down to two options.  One is a form of ZK rollups, and the other is what I call "naive rollups".  I'll create a separate thread about naive rollups and send a writeup about it.

It might be reasonable to use moons in the meantime as a stopgap way to get people on the network for free.  Of course, eventually they'll want sovereign planets, but since there's essentially no kernel work involved, maybe it's worth it for now.

On Thu, Feb 18, 2021 at 2:14 PM, Christopher King <ch...@cking.me> wrote:

Philip, did you decide on an approach?

On Thu, Jan 28, 2021 at 8:16 AM Mike Gogulski <mike@gogulski.com> wrote:

Worth mentioning: Dapper FLOW is a smart contract blockchain platform specifically designed for NFTs, created by the CryptoKitties folks. They had an IEO on CoinList in September and the token just started trading (though IEO buyers have a 1-year lockup).

https://www.onflow.org/primer

On Tue, Jan 26, 2021 at 7:32 PM Mike Gogulski <mike@gogulski.com> wrote:

I might be persuaded to toss a star into the bounty pool myself.

To unsubscribe from this group and stop receiving emails from it, send an email to dev+unsubscribe@urbit.org.

[Christopher King]

Thanks Philip. Are there technical limitations to moons beyond not being associated with an immutable cryptographic identity? That is, will the user have basically the same experience on the network?

On Fri, Feb 19, 2021 at 4:12 PM Philip Monk <phi...@tlon.io> wrote:

We're close, we have it basically narrowed down to two options.  One is a form of ZK rollups, and the other is what I call "naive rollups".  I'll create a separate thread about naive rollups and send a writeup about it.

It might be reasonable to use moons in the meantime as a stopgap way to get people on the network for free.  Of course, eventually they'll want sovereign planets, but since there's essentially no kernel work involved, maybe it's worth it for now.

On Thu, Feb 18, 2021 at 2:14 PM, Christopher King <ch...@cking.me> wrote:

Philip, did you decide on an approach?

On Thu, Jan 28, 2021 at 8:16 AM Mike Gogulski <mi...@gogulski.com> wrote:

Worth mentioning: Dapper FLOW is a smart contract blockchain platform specifically designed for NFTs, created by the CryptoKitties folks. They had an IEO on CoinList in September and the token just started trading (though IEO buyers have a 1-year lockup).

https://www.onflow.org/primer

To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@urbit.org.

--

Best,

Chris

[Philip Monk]

They'll have basically the same experience, yes.  You should make sure the planet they're from isn't used for other purposes, because by default landscape apps let you impersonate the planet (see https://github.com/urbit/urbit/issues/4360).  It might even be a good idea to disable landscape apps on that planet with |fade.

It looks like on landscape moons by default will be displayed as the planet name with infix ^ instead of -.  This isn't great, and maybe we should consider changing that.  They can set their own profile name, though.

On Fri, Feb 19, 2021 at 2:43 PM, Christopher King <ch...@cking.me> wrote:

Thanks Philip. Are there technical limitations to moons beyond not being associated with an immutable cryptographic identity? That is, will the user have basically the same experience on the network?

To unsubscribe from this group and stop receiving emails from it, send an email to dev+unsubscribe@urbit.org.

--

Best,

Chris

[Matilde Park]

> It looks like on landscape moons by default will be displayed as the planet name with infix ^ instead of -. This isn't great, and maybe we should consider changing that. They can set their own profile name, though.

Is this different from how cite works on Arvo-side?

—
~haddef-sigwen
https://urbit.org

> On Feb 19, 2021, at 5:51 PM, Philip Monk <phi...@tlon.io> wrote:
>
> They'll have basically the same experience, yes. You should make sure the planet they're from isn't used for other purposes, because by default landscape apps let you impersonate the planet (see https://github.com/urbit/urbit/issues/4360). It might even be a good idea to disable landscape apps on that planet with |fade.
>
> It looks like on landscape moons by default will be displayed as the planet name with infix ^ instead of -. This isn't great, and maybe we should consider changing that. They can set their own profile name, though.
>
>
> On Fri, Feb 19, 2021 at 2:43 PM, Christopher King <ch...@cking.me> wrote:
> Thanks Philip. Are there technical limitations to moons beyond not being associated with an immutable cryptographic identity? That is, will the user have basically the same experience on the network?
>

> On Fri, Feb 19, 2021 at 4:12 PM Philip Monk <phi...@tlon.io> wrote:
> We're close, we have it basically narrowed down to two options. One is a form of ZK rollups, and the other is what I call "naive rollups". I'll create a separate thread about naive rollups and send a writeup about it.
>
> It might be reasonable to use moons in the meantime as a stopgap way to get people on the network for free. Of course, eventually they'll want sovereign planets, but since there's essentially no kernel work involved, maybe it's worth it for now.
>
>
> On Thu, Feb 18, 2021 at 2:14 PM, Christopher King <ch...@cking.me> wrote:
> Philip, did you decide on an approach?
>
>
> On Thu, Jan 28, 2021 at 8:16 AM Mike Gogulski <mi...@gogulski.com> wrote:
> Worth mentioning: Dapper FLOW is a smart contract blockchain platform specifically designed for NFTs, created by the CryptoKitties folks. They had an IEO on CoinList in September and the token just started trading (though IEO buyers have a 1-year lockup).
>
> https://www.onflow.org/primer
>

> On Tue, Jan 26, 2021 at 7:32 PM Mike Gogulski <mi...@gogulski.com> wrote:
> I might be persuaded to toss a star into the bounty pool myself.
>

> On Tue, Jan 26, 2021 at 7:24 PM Christopher King <ch...@cking.me> wrote:
> Philip, please keep me updated. I'd like to propose a bounty on this when parallelization is possible. I have a vested interest in solving this.
>

> On Sun, Jan 24, 2021 at 4:32 PM Philip Monk <phi...@tlon.io> wrote:
> I would love to Manhattan this project, and we absolutely would be willing to pay stars to speed it up. I'm all ears for ways to speed up this project.
>
> Frustratingly, we haven't quite decided the outline of the solution - there's still three possible solutions. I don't know how to parallelize that since one person needs a practical understanding of each option (and be immersed in Urbit) to make that recommendation.
>
> I hope to decide the technical solution in the next two or three weeks. Then, we can make a plan for implementing and migrating, and that could definitely have bounty-able tasks.
>

> On Sun, Jan 24, 2021, 10:51 Christopher King <ch...@cking.me> wrote:
> This ought to be Manhattan Project-ified. It's the largest current obstacle to network growth. Is there appetite for bounty proposals on this?
>
>
> On Fri, Jan 22, 2021 at 2:27 PM Philip Monk <phi...@tlon.io> wrote:
> For those interested in specifics, the three options under consideration are Starkware's Cairo system (ZK rollup, STARKs), Matter Labs's zkSync/Zinc (ZK rollup, SNARKs), and Optimism's OVM (Optimistic Rollup).
>
> I've writtten a minimal prototype in Cairo (https://github.com/urbit/azimuth-cairo) and I've read the Zinc docs. I hope to write something in Zinc soon and maybe even deploy it to the Rinkeby testnet to play around with in the wild. Then Optimism will be the next thing to evaluate.
>
>
> On Fri, Jan 22, 2021 at 11:14 AM, Christopher King <ch...@cking.me> wrote:
> Thanks for the update, Galen. I'm glad it's still an active area of research. It may be worth including brief updates on the matter in future Tlon newsletter emails in the future.
>
>
> On Fri, Jan 22, 2021 at 2:10 PM Galen Wolfe-Pauly <ga...@tlon.io> wrote:
> > In the next few weeks we'll try to lay them out here and dig in to Ted's proposal for a proof-of-authority approach.
>
> Whoops—sorry for not sticking to that commitment.
>
> I'll give a very off-the-cuff update here, and perhaps Philip can chime in since he's taken this up as his primary area of work. So, briefly:
>
> - While self-hosted, proof of authority (ish) solutions are interesting because of their lack of dependencies, it seems overly ambitious to implement one in short-order. We've continued to think through how an approach like this might work, but we're not actively pursuing it.
> - Our research on possible layer 2 solutions was worthwhile, and Philip is now going through each of the candidates and building out prototypes to see how they fare. After doing that, we intend to pick one and try to move forward. Better not to comment on timing at this stage, but we're moving forward.
>
> It's true that the gas prices are a very real and painful problem. We have continued to pre-spawn planets, but it's not enough to keep up with demand. This is probably our biggest scaling problem and we're working on it.
>

> To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@urbit.org.
>
> --
>
> Best,
> Chris
>