Lets rename account to space

[Gozala]

In the internal discussion @jchris proposed that we:

based on this and the previous note, I think we should rename accounts to spaces in the code ASAP. Otherwise spaces and whatever the real account domain object turns out to be are gonna get muddied.

Here some more reasoning from @jchris on why from that thread

the problem is that the thing we are calling accounts is not accounts, we have something else we will call accounts. Space are things each account may have many of. (I'm assuming an account is the thing tied to a billing contact, and that you might want to fund more than one space from the same account.)

[Gozala]

While reflecting on name account which I came up with, or rather borrowed from Solana, I have following observations:

1. I was actually confused by the fact that Solana called their thing an account, but then I got used to it and it started to make sense. Yet initial confusion is probably what we can expect from others if we stick to name account.
2. I think everyone I have spoken to was confused by name account, some less then others, but people who did not liked the name had a very strong feeling about it.
3. Most cases I find myself explaining our notion of account as "memory space", which is why I started to feel that maybe "space" is a better term.
4. Most people do not seem to have preconceived notion for "space" term which, in my experience, seems to put them into listening mode as opposed to triggering internal conflict due to mismatched expectation.
5. I do like that "space" is bit more abstract than "memory space", as it can encompass more things we're interested in pursuing.
6. Just like @jchris I've also started to recognize separate entities one acting like "home space" and other like "payment account". Having different names might help down the line when communicating this concepts.

All this comes with a caveat - Space, Account, Agent all are identified by a did:key and there is nothing preventing a user from using same key for all three or some subset. That said, I think it's ok if same entity plays multiple roles in the system, in fact I suspect that same entity probably will play role of the Account and a Space, it is still good idea to have different terms though.

[jchris]

I'm guessing that an account will be a business object of web3.storage, and may not even be represented in the protocol.

[gobengo]

@Gozala in your model is there a meaningful difference between what you call 'memory space' and what you imagine I might mean by 'storage space'? Since we use 'storage' so many places already (eg web3.storage), I'm wondering if you introduced the 'memory' terminology intentionally to distinguish from 'storage'.

[Gozala]

@Gozala in your model is there a meaningful difference between what you call 'memory space' and what you imagine I might mean by 'storage space'?

No. I also tend to write (memory) space and think if it as qualifier not really as a separate concept

Perhaps that’s confusing and we should use (storage) space ? I just reached for memory space as its existing concept and I often used it to explain role account previously played

[Gozala]

Since we use 'storage' so many places already (eg web3.storage), I'm wondering if you introduced the 'memory' terminology intentionally to distinguish from 'storage'.

I have to say idea of changing store/add to memory/store had certainty crossed my mind, but that ship has probably sailed

[gobengo]

Perhaps that’s confusing and we should use (storage) space ?

Personally I think so.

Memory is what your computer uses to store data temporarily, while storage is where you save files permanently.
(via https://www.hp.com/us-en/shop/tech-takes/computer-memory-vs-storage )

In general it seems like we are trying to offer something closer to storage that is permanent/durable (as long as you pay your bill). To me in computers 'memory' usually implies RAM or some kind of temporary memory that may go away e.g. if the power goes out.

[hugomrdias]

This has been done in access and upload.