RFC: Planetoids

157 views
Skip to first unread message

Philip Monk

unread,
Sep 14, 2020, 10:50:03 PMSep 14
to urbit-dev
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.

planetoids.txt

Ted Blackman

unread,
Sep 15, 2020, 12:17:52 PMSep 15
to Philip Monk, urbit-dev
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

Matilde Park

unread,
Sep 15, 2020, 12:37:33 PMSep 15
to Ted Blackman, Philip Monk, urbit-dev
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

unread,
Sep 15, 2020, 3:22:21 PMSep 15
to urbit-dev
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

signature.asc

Galen Wolfe-Pauly

unread,
Sep 15, 2020, 3:59:14 PMSep 15
to urbit-dev
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

unread,
Sep 15, 2020, 4:07:07 PMSep 15
to Galen Wolfe-Pauly, urbit-dev
> 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

unread,
Sep 15, 2020, 4:13:01 PMSep 15
to Matilde Park, urbit-dev
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

unread,
Sep 15, 2020, 5:03:10 PMSep 15
to Galen Wolfe-Pauly, Matilde Park, urbit-dev
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

Ted Blackman

unread,
Sep 15, 2020, 5:11:31 PMSep 15
to Galen Wolfe-Pauly, urbit-dev, Matilde Park
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


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

unread,
Sep 15, 2020, 5:15:15 PMSep 15
to Ted Blackman, Galen Wolfe-Pauly, urbit-dev, Matilde Park
> 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


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


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

unread,
Sep 15, 2020, 9:52:04 PMSep 15
to Anthony Arroyo, Galen Wolfe-Pauly, urbit-dev, Matilde Park, Ted Blackman
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


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


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. 
rental-planets.txt

~forfel-norfel

unread,
Sep 17, 2020, 9:55:46 AMSep 17
to urbit-dev, phi...@tlon.io, ga...@tlon.io, urbit-dev, Matilde Park, ~rovnys-ricfer, Anthony
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

unread,
Sep 17, 2020, 10:02:10 AMSep 17
to ~forfel-norfel, urbit-dev, phi...@tlon.io, ga...@tlon.io, Matilde Park, ~rovnys-ricfer, Anthony
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

unread,
Sep 17, 2020, 10:48:35 AMSep 17
to d...@urbit.org
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

unread,
Sep 17, 2020, 11:24:47 AMSep 17
to urbit-dev, Rob Myers
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

unread,
Sep 17, 2020, 11:29:30 AMSep 17
to ~forfel-norfel, urbit-dev, Rob Myers
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

unread,
Sep 17, 2020, 8:06:26 PMSep 17
to Vitor Py, ~forfel-norfel, urbit-dev, Rob Myers
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

unread,
Sep 18, 2020, 2:14:55 PMSep 18
to Galen Wolfe-Pauly, Vitor Py, ~forfel-norfel, urbit-dev, Rob Myers
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

unread,
Sep 21, 2020, 12:15:52 AMSep 21
to Christopher King, Vitor Py, ~forfel-norfel, urbit-dev, Rob Myers
(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

unread,
Sep 21, 2020, 12:31:43 AMSep 21
to Galen Wolfe-Pauly, Christopher King, Vitor Py, urbit-dev, Rob Myers
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

unread,
Sep 21, 2020, 12:48:35 AMSep 21
to ~forfel-norfel, Christopher King, Vitor Py, urbit-dev, Rob Myers
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

unread,
Sep 21, 2020, 1:13:38 AMSep 21
to urbit-dev
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

unread,
Sep 21, 2020, 2:31:28 AMSep 21