15:43:35 <RRSAgent> RRSAgent has joined #storage-buckets
15:43:35 <RRSAgent> logging to https://www.w3.org/2020/10/29-storage-buckets-irc
15:43:54 <oyiptong> rssagent, bookmark
15:45:18 <oyiptong> rrsagent, prepare this meeting
15:45:18 <RRSAgent> I'm logging. I don't understand 'prepare this meeting', oyiptong.  Try /msg RRSAgent help
15:45:27 <oyiptong> prepare this meeting
15:46:49 <oyiptong> rssagent, this meeting is about Storage Buckets
15:49:19 <oyiptong> zakim, prepare this meeting
15:49:19 <Zakim> RRSAgent, make logs Public
15:49:20 <Zakim> Meeting: Storage Buckets API
15:49:29 <oyiptong> zakim, this is Zoom 815 1361 9748
15:49:29 <Zakim> got it, oyiptong
15:50:07 <oyiptong> present+ oyiptong
15:50:21 <oyiptong> zakim, who is here?
15:50:21 <Zakim> Present: oyiptong
15:50:23 <Zakim> On IRC I see RRSAgent, Zakim, ayu, asuth, danyao, masaya_ikeo, oyiptong, Mek
15:52:07 <oyiptong> agenda+ Discussion on Storage Buckets API Proposal https://github.com/WICG/storage-buckets/blob/gh-pages/explainer.md
15:52:12 <lgombos___> lgombos___ has joined #storage-buckets
15:52:29 <MasakazuKitahara> MasakazuKitahara has joined #storage-buckets
15:54:23 <ayu> present+ Ayu Ishii (Google)
15:54:48 <ayu> zakim, who is here?
15:54:48 <Zakim> Present: oyiptong, Ayu, Ishii, (Google)
15:54:50 <Zakim> On IRC I see MasakazuKitahara, lgombos___, RRSAgent, Zakim, ayu, asuth, danyao, masaya_ikeo, oyiptong, Mek
15:54:52 <tidoust> tidoust has joined #storage-buckets
15:55:30 <oyiptong> zakim, list agenda
15:55:31 <Zakim> I see 1 item remaining on the agenda:
15:55:31 <Zakim> 1. Discussion on Storage Buckets API Proposal https://github.com/WICG/storage-buckets/blob/gh-pages/explainer.md [from oyiptong]
15:57:25 <asuth> present+ Andrew Sutherland
15:59:36 <oyiptong> zakim, start this meeting
15:59:36 <Zakim> RRSAgent, make logs Public
15:59:37 <Zakim> Meeting: Storage Buckets API
15:59:55 <jsbell> jsbell has joined #storage-buckets
16:00:15 <Mek> present+
16:00:33 <lgombos___> present+
16:00:41 <oyiptong> zakim, who is here?
16:00:41 <Zakim> Present: oyiptong, Ayu, Ishii, (Google), Andrew, Sutherland, Mek, lgombos___
16:00:43 <Zakim> On IRC I see jsbell, tidoust, MasakazuKitahara, lgombos___, RRSAgent, Zakim, ayu, asuth, danyao, masaya_ikeo, oyiptong, Mek
16:00:54 <jsbell> present+ Joshua Bell
16:00:59 <tidoust> present+ Francois_Daoust
16:01:41 <pwnall> pwnall has joined #storage-buckets
16:01:48 <pwnall> present+ Victor Costan (Google)
16:02:25 <kenchris> kenchris has joined #storage-buckets
16:02:35 <MikeSmith> MikeSmith has joined #storage-buckets
16:02:38 <oyiptong> zakim, take up agendum 1
16:02:38 <Zakim> agendum 1. "Discussion on Storage Buckets API Proposal https://github.com/WICG/storage-buckets/blob/gh-pages/explainer.md" taken up [from oyiptong]
16:03:13 <asully> asully has joined #storage-buckets
16:03:34 <muodov> muodov has joined #storage-buckets
16:03:59 <oyiptong> starting soon, to let people join
16:04:21 <oyiptong> in 1 more minute
16:05:14 <oyiptong> starting now
16:05:35 <oyiptong> Ayu Ishii presenting, Victor Costan helping as well
16:06:02 <oyiptong> presentation: goals, use-cases, explainer overview, Q&Discussions
16:06:20 <oyiptong> problem: 1 default bucket for storage. they lose all or none of their data during storage pressure
16:06:27 <oyiptong> no tools to better manage their storage
16:06:44 <oyiptong> could prioritize some data, e.g. songs and playlist
16:06:56 <oyiptong> goal: give apps more control over how data is stored and evicted
16:07:08 <oyiptong> with buckets, apps can partition by data, cache, etc
16:07:11 <bkardell___> bkardell___ has joined #storage-buckets
16:07:20 <oyiptong> e.g. favorite songs, playlists to be evicted last
16:07:33 <oyiptong> more use-cases: email clients can cache messages and attachments
16:07:38 <oyiptong> drafts not stored yet on the server
16:07:46 <oyiptong> with browser eviction, all data would be lost, including drafts not sent yet
16:07:56 <oyiptong> with buckets, this data could be partitioned and preserved
16:08:10 <oyiptong> policies: a bucket could be evicted on storage pressure
16:08:13 <AramZS> AramZS has joined #storage-buckets
16:08:21 <oyiptong> and some data to be evicted last
16:08:36 <oyiptong> tradeoffs, data could survive power failures, at the cost of battery consumption
16:08:45 <oyiptong> how buckets could be used: 1 bucket per account
16:08:54 <JohnWilander> JohnWilander has joined #storage-buckets
16:09:01 <oyiptong> on logout, data cleanup would be the deletion of the specific bucket
16:09:08 <oyiptong> code example: how to create a bucket
16:09:17 <oyiptong> options for durability and persistence
16:09:25 <oyiptong> in example: strict durability to minimize data loss
16:09:37 <oyiptong> title: for the UA to display the bucket title in the UI
16:09:50 <JohnWilander> present+
16:09:54 <oyiptong> example was unimportant bucket
16:10:05 <JohnWilander> q+
16:10:09 <oyiptong> for managing quota, proposing a quota option
16:10:35 <oyiptong> expires option, to ensure data isn't accessible after a certain time
16:11:00 <oyiptong> deleting buckets. delete API. could be used on user logout
16:11:15 <oyiptong> service workers: each storage bucket could store SW registrations
16:11:25 <pwnall> Slides: https://docs.google.com/presentation/d/1q8wRn2Q3BddAErKd5Sq6vDx4w6W5UqCEd6PaBxqJ0Kg/
16:11:39 <oyiptong> early state. with tag review. want to get feedback
16:11:47 <annevk> annevk has joined #storage-buckets
16:11:49 <oyiptong> floor open to questions / discussion
16:11:57 <oyiptong> zakim, who is on the queue?
16:11:57 <Zakim> I see JohnWilander on the speaker queue
16:12:17 <bkardell___> q+
16:12:24 <AramZS> q+
16:12:24 <AramZS> present+
16:12:24 <AramZS> q+
16:13:31 <muodov> q+
16:14:46 <oyiptong> zakim, oyiptong acks JohnWilander
16:14:46 <Zakim> I don't understand 'oyiptong acks JohnWilander', oyiptong
16:15:16 <annevk> JohnWilander: https://github.com/WICG/storage-buckets/blob/gh-pages/explainer.md#storage-policy-expiration
16:15:53 <oyiptong> zakim, ack next
16:15:54 <Zakim> I see bkardell___, AramZS, muodov on the speaker queue
16:16:07 <JohnWilander> https://github.com/privacycg/storage-partitioning
16:16:21 <oyiptong> for cookies, no plans on supporting cookies in buckets
16:16:27 <asuth> The Storage spec has a concept of sheds and shelves which would relate to the partitioning: https://storage.spec.whatwg.org/#storage-shelves
16:16:45 <asuth> Buckets explicitly already operate at a granularity beneath those.
16:16:54 <oyiptong> expiry: guarantee is that data is inaccessible after expiration
16:17:04 <oyiptong> it won't be retrievable when storage pressure occurs
16:17:15 <oyiptong> does proposal introduce expiry for storage?
16:17:26 <oyiptong> part of the option, but not a required option
16:17:39 <oyiptong> if you don't state an expiry, it's in memory only?
16:17:48 <oyiptong> should've been there from the start
16:18:13 <oyiptong> on cookies: when starting buckets, tackled quota managed storage
16:18:30 <oyiptong> cookies: synchronous API, etc. each browser has a small fixed amount of quota
16:18:37 <oyiptong> does everything hang off of buckets? yes
16:18:45 <oyiptong> will it happen in the next few years? unlikely
16:18:50 <oyiptong> with proposal, starting with small steps
16:19:00 <oyiptong> fix problems, and iterate
16:19:26 <oyiptong> cookies are special... wondering if allowing sites to somehow tell the browser to delete cookies, and keeping some, e.g. login cookies
16:19:36 <oyiptong> partitioning: partitioned+ storage buckets?
16:19:56 <oyiptong> talking to folks in Google who are more familiar. following options, not ready for scrutiny
16:20:15 <oyiptong> looking at 1P contexts first, 3P later
16:20:29 <oyiptong> probably more specs/explainers in addition later to this proposal
16:20:46 <oyiptong> shelves and buckets are already explicit. partitioning is already answered by the spec
16:20:53 <oyiptong> depends on how CG interacts
16:21:00 <oyiptong> this explainer does not change any of how that works
16:21:16 <bkardell___> q?
16:21:35 <oyiptong> zakim, ack next
16:21:36 <Zakim> I see AramZS, muodov on the speaker queue
16:22:07 <AramZS> AramZS has joined #storage-buckets
16:22:07 <oyiptong> unaware of this until this week. no time to consume in full, but appreciate the problems this is trying to solve
16:22:22 <muodov> q-
16:22:26 <oyiptong> eviction of a whole origin? carefully designed, but hand-wavy and not good data on this
16:22:31 <oyiptong> no aspect seems great
16:22:55 <oyiptong> earlier this year webkit made changes to eviction policy. due to privacy, good explanation
16:23:05 <oyiptong> but people reacted based on misunderstanding on how it works in other browsers
16:23:13 <oyiptong> opened an issue on chrome
16:23:25 <oyiptong> use low-end device for 5 years
16:23:30 <oyiptong> things get evicted all the time
16:23:48 <oyiptong> no discussion about that and what that means to your ability to have cache
16:23:59 <oyiptong> know of efforts to collect data on how often eviction happens?
16:24:00 <pwnall> Our latest attempt at documenting some of this behavior: https://web.dev/storage-for-the-web/
16:24:17 <oyiptong> we do collect eviction data
16:24:27 <oyiptong> (we): Chrome
16:24:40 <oyiptong> could make it more clear around evictions to incentivize sites to use storage
16:24:52 <oyiptong> good suggestion. hard to define what the rules would be
16:25:00 <oyiptong> could eviction data be published?
16:25:25 <oyiptong> based on UA? what's the policy around this?
16:25:51 <oyiptong> related to explainer: let developers give more preferences on how data should be evicted
16:26:23 <oyiptong> until recently, how eviction works was not a well understood process
16:26:32 <oyiptong> we now have a better understanding of all the cases
16:26:53 <oyiptong> we have published an article that explains what we do and what other browsers do
16:26:55 <muodov> q+
16:26:59 <oyiptong> https://web.dev/storage-for-the-web/
16:27:06 <oyiptong> we have metrics and we'll see what we can release
16:27:13 <oyiptong> (we): Chrome
16:27:28 <oyiptong> goals focusing on prioritization, could segment by users
16:27:38 <oyiptong> offering new features around storage... expiry
16:27:46 <zhaoz_google> zhaoz_google has joined #storage-buckets
16:27:57 <oyiptong> some users have to use it forregulatory reasons
16:28:02 <oyiptong> zakim, q?
16:28:02 <Zakim> I see AramZS, muodov on the speaker queue
16:28:11 <oyiptong> zakim, ack next
16:28:12 <Zakim> I see muodov on the speaker queue
16:28:20 <oyiptong> aram: Eng Director at WaPo
16:28:31 <oyiptong> incentive to evict data less?
16:28:37 <oyiptong> privacy focused browsers come to mind
16:28:50 <oyiptong> what's the incentive to the UA not to evict to be more private?
16:28:57 <oyiptong> (or to evict?)
16:29:13 <oyiptong> what incentive can i give to a browser to not evict some data because it isn't privacy sensitive?
16:29:39 <oyiptong> still figuring out what it means RE: 3P storage
16:29:55 <oyiptong> complicated space, lots of options, nothing useful to say at this point
16:30:03 <oyiptong> asuth: won't impact privacy behavior at all
16:30:10 <oyiptong> clearing origin clears everything about this origin
16:30:19 <oyiptong> exiting the session? it's all going to get cleared
16:30:28 <oyiptong> this is just giving options surrounding eviction options
16:30:37 <oyiptong> LRU? evicted
16:30:57 <oyiptong> movie-watching site a kid watches every day,   will let browser evict data that's already used
16:31:08 <oyiptong> i.e. FMV data
16:31:18 <JohnWilander> q+
16:31:28 <oyiptong> exposing more granular things to user: delete some data, and not other stuff... delete data but not UI
16:31:53 <oyiptong> storage gets cleared for a few reasons: 1) user clearing browsing data, proposal has no effect on that
16:31:58 <oyiptong> will clear all buckets
16:32:06 <oyiptong> could be more options there? not yet
16:32:13 <oyiptong> 2) under storage pressure, disk is getting full
16:32:17 <oyiptong> this proposal applies
16:32:22 <oyiptong> opted in by the site
16:32:29 <oyiptong> default behavior is that under pressure, all data is wiped
16:32:43 <oyiptong> if a user is clearing data for privacy reasons, all data will be cleared
16:32:50 <oyiptong> zakim, q?
16:32:50 <Zakim> I see muodov, JohnWilander on the speaker queue
16:32:59 <oyiptong> zakim, ack next
16:33:00 <Zakim> I see JohnWilander on the speaker queue
16:33:34 <oyiptong> question: do you consider automatic expiration? how session storage automatically expires
16:33:41 <oyiptong> or session cookies removed when browser is closed?
16:33:52 <oyiptong> not currently in the explainer
16:33:57 <oyiptong> it could be something we create an issue for
16:34:00 <oyiptong> and consider use-cases
16:34:19 <oyiptong> could add to the explainer after elaboration, perhaps
16:34:35 <oyiptong> muodov: will elaborate
16:34:45 <asuth> There is a storage spec issue on sesssion buckets already: https://github.com/whatwg/storage/issues/71
16:34:57 <oyiptong> could be copied over in popups?
16:35:08 <oyiptong> does the use-case rely on that?
16:35:20 <oyiptong> popups: window.open, target=blank, etc
16:35:23 <bkardell___> q+
16:35:31 <bkardell___> q++
16:35:35 <oyiptong> dynamically created subdomains, using sessionstorage to have some state
16:35:45 <oyiptong> goes away when you close the tab
16:35:51 <oyiptong> survives tab reload
16:36:11 <oyiptong> would be very nice if it is possible to separate/partition storage
16:36:42 <oyiptong> bkardell jumps the queue: company admits they don't care which tab a user is in. inability to sync data is a nightmare
16:36:48 <bkardell___> q-
16:36:53 <oyiptong> zakim, q?
16:36:53 <Zakim> I see JohnWilander, + on the speaker queue
16:36:56 <oyiptong> zakim, ack next
16:36:57 <Zakim> I see + on the speaker queue
16:37:06 <annevk> bkardell___: so it's quite specific, if the user opens two tabs independently they wouldn't share sessionStorage
16:37:14 <annevk> bkardell___: and you'd have to use BroadcastChannel or some such
16:37:24 <oyiptong> referring to functionality in Safari: deleting website data for domains
16:37:36 <annevk> bkardell___: sessionStorage is only copied over from a starting tab to a new one opened from there
16:37:37 <oyiptong> not because there's a lack of storage or user going through storage settings
16:37:46 <oyiptong> part of privacy protection
16:37:56 <oyiptong> maybe there's a way for buckets to inform this feature
16:38:04 <bkardell___> s/admits they don't care/was adamant that it was necessary to reflect your 'session' in any tabs you were in, and they did open new windows. But also that was a nightmare. For whatever that is worth
16:38:10 <oyiptong> data important for functionality, take that in consideration before clearing data
16:38:18 <oyiptong> chrome lacks same-site cookies by default
16:38:26 <oyiptong> same-site none: cookies i intend to use in a partitioned context
16:38:29 <oyiptong> more likely to go away?
16:38:38 <oyiptong> feature: clear all cookies that could be used in a 3P context
16:38:42 <oyiptong> not an outlandish thought
16:38:52 <oyiptong> could ever get to a good faith situation there?
16:39:02 <oyiptong> where functionality in buckets wouldn't be misused to store tracking data
16:39:32 <oyiptong> JohnWilander mentioning to muodev: sessionstorage similar, per-tab, per-session
16:39:36 <oyiptong> sessionstorage is weird in other ways
16:39:40 <oyiptong> ties to the tab not to the origin
16:39:47 <oyiptong> should be revisited
16:39:53 <oyiptong> muodev: that's what's missing
16:39:57 <asuth> q?
16:40:01 <asuth> q+
16:40:08 <zhaoz> zhaoz has joined #storage-buckets
16:40:09 <oyiptong> q- +
16:40:28 <oyiptong> storage buckets is an opportunity to fix several of the problematic things in earlier storage specs
16:40:41 <oyiptong> aram: yes, exactly what was in mind
16:40:49 <oyiptong> would not rely on the occurrence of this API right now
16:40:52 <oyiptong> but hopeful
16:41:01 <oyiptong> data not accessible to 3P, so don't clear
16:41:02 <oyiptong> etc
16:41:20 <oyiptong> data is protected, that makes it not accessible to 3P in a more dynamic way, so don't clear it
16:41:29 <oyiptong> looking for ways to make it easier to retain a login for users
16:41:38 <oyiptong> while respecting the choice of UA RE: privacy
16:41:41 <oyiptong> and dynamic clearing for that reason
16:41:45 <oyiptong> might not be the proposal
16:41:49 <oyiptong> but might be a future proposal?
16:41:52 <annevk> q?
16:41:53 <oyiptong> zakim, q?
16:41:54 <Zakim> I see asuth on the speaker queue
16:42:10 <oyiptong> zakim, ack next
16:42:11 <Zakim> I see no one on the speaker queue
16:42:18 <oyiptong> durability?
16:42:42 <oyiptong> sessionstorage, storage gets cleared, association with tab and cleared on shutdown
16:42:52 <oyiptong> should there be a bucket that gets cleared on browser shutdown?
16:43:13 <oyiptong> muodov: ideally, replicate sessionstorage, tied to tab
16:43:31 <oyiptong> question more general: cookie. clearing when browser is shutdown? strange
16:43:50 <oyiptong> question is more like: would we consider any type of automatic removal that's not defined by an expiration date
16:44:06 <oyiptong> q+ JohnWilander
16:44:12 <oyiptong> zakim, ack next
16:44:14 <Zakim> I see no one on the speaker queue
16:44:20 <oyiptong> HTTP-only cookies?
16:44:25 <oyiptong> protocol things, not JS
16:44:30 <oyiptong> can't get to HTTP-only cookies
16:44:34 <oyiptong> things goes towards what you want
16:44:48 <oyiptong> want ability as a dev to say: this is my indexeddb. even if i run 3P code, they shouldn't get access to this
16:44:57 <oyiptong> please consider this more isolated and not tainted... keep it around
16:45:06 <oyiptong> aram: very interesting dimension
16:45:15 <oyiptong> bucket we wish to be very isolated from any 3P
16:45:20 <oyiptong> in exchange for that, store it longer?
16:45:25 <oyiptong> could be passed by network request...
16:45:33 <oyiptong> 1P leaking deliberately to 3P, different use-case
16:45:36 <pwnall> q+
16:45:45 <oyiptong> could achieve the same by opening an iframe and never load 3P data there
16:45:52 <oyiptong> "is logged in" very interesting idea
16:45:57 <oyiptong> talking about a 3rd state
16:46:08 <oyiptong> data stored and available to site, data evicted for whatever reason
16:46:14 <oyiptong> in the middle, "is logged in", hiding data
16:46:29 <oyiptong> some time has passed. UA hides data, keeps it around
16:46:32 <oyiptong> e.g. email drafts
16:46:41 <oyiptong> could find middle ground with "forever storage"
16:46:44 <oyiptong> tied to user being logged in
16:46:51 <zero_liu> zero_liu has joined #storage-buckets
16:46:58 <oyiptong> q?
16:47:10 <oyiptong> WaPo could be early devs/testers
16:47:16 <oyiptong> lots of work right now, but after that
16:47:18 <oyiptong> interested
16:47:29 <oyiptong> zakim, ack next
16:47:30 <Zakim> I see no one on the speaker queue
16:47:31 <bkardell___> this is very interesting, thank you for this session
16:47:37 <oyiptong> please file github issues
16:47:40 <oyiptong> to continue discussion
16:47:47 <asuth> q+
16:47:48 <oyiptong> want more clarity and use-cases
16:47:55 <oyiptong> this is the 1st version of this API
16:48:00 <oyiptong> will iterate
16:48:19 <oyiptong> zakim, ack next
16:48:20 <Zakim> I see no one on the speaker queue
16:48:25 <oyiptong> q+ zero_liu
16:48:36 <oyiptong> storage specs has endpoints
16:48:48 <oyiptong> would imply that this requires File System Access
16:48:59 <oyiptong> next-steps? one small point of confusion
16:49:10 <oyiptong> scoping-wise: chrome indicated they were thinking of re-doing quota management
16:49:16 <oyiptong> not dependent on free disk-space
16:49:30 <oyiptong> if quota bucket storage is intended to be part of that change, or informative?
16:49:40 <oyiptong> document how eviction works with quota management?
16:49:45 <annevk> q?
16:49:56 <oyiptong> answer: yes. would love help to write the spec to get it right
16:50:08 <oyiptong> chrome around quota: don't consider free disk space anymore when computing quota
16:50:15 <oyiptong> because of security issues discussed in the explainer
16:50:27 <oyiptong> hoping buckets gives sites a way to explain how storage is structure
16:50:32 <oyiptong> future: allocating and logging quota
16:50:39 <oyiptong> firefox has some thoughts
16:50:46 <oyiptong> should consider opinions together
16:50:59 <oyiptong> doing some work there, good direction, shouldn't be a big feature bloat on the spec
16:51:09 <oyiptong> explainer -> diffs on storage specs, do small steps
16:51:11 <oyiptong> zakim, q?
16:51:11 <Zakim> I see zero_liu on the speaker queue
16:51:21 <oyiptong> zakim, ack next
16:51:22 <Zakim> I see no one on the speaker queue
16:51:30 <oyiptong> zero: on internal Google team
16:51:40 <oyiptong> chrome and firefox: different models to grant permissions
16:51:47 <oyiptong> popups vs implicit grant
16:52:00 <oyiptong> will allow users to define and persist permissions in different buckets?
16:52:16 <oyiptong> existing mechanisms from UAs? challenging for popup mechanism to deliver in this new world
16:52:21 <oyiptong> want to hear from both Chrome and Firefox
16:52:30 <oyiptong> any idea of unifying the grant process?
16:52:55 <oyiptong> asuth: storage spec specifies a permission to get the ability to persist things
16:52:59 <oyiptong> request persistence or not
16:53:08 <oyiptong> browsers don't want to standardize UX on how that works
16:53:16 <oyiptong> Firefox: an explicit prompt, no plans to change that
16:53:32 <oyiptong> it's always difficult to provide informed consent to users when they're not under duress
16:53:36 <oyiptong> chrome uses frecency
16:53:46 <MikeSmith> q+ to ask about where this spec will live
16:53:51 <oyiptong> buckets allows firefox to provide more data to provide stronger things there
16:54:02 <oyiptong> firefox as a UA: goal not to provide a contract to a site to never delete
16:54:12 <oyiptong> it will be UA-biased. UI won't be standardized
16:54:28 <oyiptong> in Chrome: no popups because there's no good way for users to make an informed decision
16:54:32 <oyiptong> aligned on general idea
16:54:41 <oyiptong> want buckets API to allow UA to make a per-bucket decision
16:54:54 <oyiptong> in a future world, if you have a small bucket, persistence could be granted without any trouble
16:55:10 <MikeSmith> https://wicg.github.io/storage-buckets/explainer#introduction “This explainer proposes changes to the Storage Standard.
16:55:15 <oyiptong> writing messaging client with encryption, keys could be stored in a bucket, and messages in another bucket that could be evicted
16:55:26 <oyiptong> similar to Firefox: persistence does not override users' will
16:55:51 <oyiptong> might show warning: hey developer, you thought this was important before, etc
16:55:55 <oyiptong> but won't block on deleting
16:56:03 <oyiptong> q?
16:56:10 <oyiptong> zakim, ack next
16:56:11 <Zakim> MikeSmith, you wanted to ask about where this spec will live
16:56:11 <Zakim> I see no one on the speaker queue
16:56:20 <oyiptong> MikeSmith from w3c in tokyo
16:56:34 <oyiptong> plan for spec to live wholly within storage standard? or to have something else in addition to that?
16:56:45 <oyiptong> would be in storage spec
16:56:48 <oyiptong> to have buckets entirely
16:57:27 <AramZS> yes, thank you!
16:57:41 <oyiptong> asuth: thanks for working on this
16:58:05 <oyiptong> please create issues and keep discussing
16:58:10 <pwnall> everyone: Please let's continue the discussion on GitHub issues!
16:58:11 <oyiptong> zakim, stop this meeting
16:58:11 <Zakim> I don't understand 'stop this meeting', oyiptong
16:58:18 <oyiptong> zakim, stop meeting
16:58:18 <Zakim> I don't understand 'stop meeting', oyiptong
16:58:41 <oyiptong> zakim, end this meeting
16:58:41 <Zakim> As of this point the attendees have been oyiptong, Ayu, Ishii, (Google), Andrew, Sutherland, Mek, lgombos___, Joshua, Bell, Francois_Daoust, Victor, Costan, JohnWilander, AramZS
16:58:44 <Zakim> RRSAgent, please draft minutes v2
16:58:44 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/29-storage-buckets-minutes.html Zakim
16:58:47 <Zakim> I am happy to have been of service, oyiptong; please remember to excuse RRSAgent.  Goodbye
16:58:51 <Zakim> Zakim has left #storage-buckets
16:59:26 <oyiptong> rssagent, excuse us
17:00:29 <oyiptong> rssagent, leave
17:00:39 <oyiptong> RRSAgent, leave
17:00:39 <RRSAgent> I see no action items