Bitcoin backups page in Private key management

[danielnordh]

PR for issue #139

Adds a page under Private Key Management with a guide to Bitcoin backups.

[pavlenex]

@danielnordh I like the general idea behind this.

I've started doing a bit closer review at first, but I then realized there are some structural issues that I feel we can address here. For starters, this whole section talks to the end-user directly. It doesn't really talk to our target audience, designers/developers. What this should do is teach the target audience how to "teach" or present this to the user, and that's the biggest missing gap to me. Lots of do's and don't actually tell end-user what to do, which felt a bit off.

The structure itself and the suggestions are good (there are some choices I am not sure I agree with ex storing seed in a jar, but that can be ironed out later on.

[danielnordh]

@danielnordh I like the general idea behind this.

I've started doing a bit closer review at first, but I then realized there are some structural issues that I feel we can address here. For starters, this whole section talks to the end-user directly. It doesn't really talk to our target audience, designers/developers. What this should do is teach the target audience how to "teach" or present this to the user, and that's the biggest missing gap to me. Lots of do's and don't actually tell end-user what to do, which felt a bit off.

The structure itself and the suggestions are good (there are some choices I am not sure I agree with ex storing seed in a jar, but that can be ironed out later on.

Agree that this speaks to a different audience, but it was deliberate.
The intention here was to have a guide for end-users that can be a reference.

We could either:

• Rewrite for the designer/developer audience, who would then have to write the version for the end-user
• Figure out where 'end-user' facing material could/should live on the site (if at all)

Personally I feel that this kind of guide is absolutely essential to get more people to self-custody.

I'll ignore your detailed comments for now until the audience for this page, and it's place on the site has been agreed.

[pavlenex]

@danielnordh I didn't know it's deliberate, do we expect end-users to visit the design guide and get an education, or should we leave that to other projects? I'm just curious, it's a good document, I just don't feel it's fitting well with the rest of the content that addresses the app creates instead of the end users.

[GBKS]

To weigh in on whether this fits into the guide, I think the content is interesting to both end-users and product-builders. Even us relatively experienced Bitcoiners are struggling with this issue. The fact that several sites exist (Glacier, Yeti, 10x) that also try to tackle this reinforces that this is a need.

I suggest turning this into a mini-project with its own microsite, possible combined with the backup builder concept (add an inheritance sheet also). End-users can use this to help them sort out their backup needs. Designers can learn by studying the different solutions. Product builders can link to this instead of having to create their own guide.

A dedicated microsite would allow for crowd-sourced contributions and localization, making it more widely useful.

We could also turn this into a larger effort that we could call the "Bitcoin User Guide". It could cover more tips (like avoiding address reuse) that are independent of which software or hardware is being used. It would fit with our larger goal of making Bitcoin easier to use.

[pavlenex]

@GBKS That's a good idea, but we should talk and consider if too much watering down the Design Guide with too many side-projects is beneficial. At the end of the day, we do want our target audience to be able to find stuff easily, if we keep "side-project" everything, it may influence the ease of navigation and the quality of content in the guide.

This is more general thought though, not specifically 1:1 related to this PR. ^

[GBKS]

Might be a good topic for the "Discussion" page.

[danielnordh]

Capturing thoughts from the sprint planning call:

• Finish up the page, OK to write for end users (preface at the beginning)
• The content can be taken and re-used in a more accessible form for end-user impact (microsites, existing user-facing sites etc.)
• Consider whether page makes more sense in Foundations or PKM

[pavlenex]

@danielnordh Do you need any help with this, what's left in your opinion so we can get this one ready for review?

[danielnordh]

I'm planning to wrap this up this week, should be ready by Friday.

[danielnordh]

Due to messed up merge history with this commit I've moved the work over to a fresh PR:
#305

[danielnordh]

PR for issue #139

Adds a page under Private Key Management with a guide to Bitcoin backups.

[pavlenex]

@danielnordh I like the general idea behind this.

I've started doing a bit closer review at first, but I then realized there are some structural issues that I feel we can address here. For starters, this whole section talks to the end-user directly. It doesn't really talk to our target audience, designers/developers. What this should do is teach the target audience how to "teach" or present this to the user, and that's the biggest missing gap to me. Lots of do's and don't actually tell end-user what to do, which felt a bit off.

The structure itself and the suggestions are good (there are some choices I am not sure I agree with ex storing seed in a jar, but that can be ironed out later on.

[danielnordh]

@danielnordh I like the general idea behind this.

I've started doing a bit closer review at first, but I then realized there are some structural issues that I feel we can address here. For starters, this whole section talks to the end-user directly. It doesn't really talk to our target audience, designers/developers. What this should do is teach the target audience how to "teach" or present this to the user, and that's the biggest missing gap to me. Lots of do's and don't actually tell end-user what to do, which felt a bit off.

The structure itself and the suggestions are good (there are some choices I am not sure I agree with ex storing seed in a jar, but that can be ironed out later on.

Agree that this speaks to a different audience, but it was deliberate.
The intention here was to have a guide for end-users that can be a reference.

We could either:

• Rewrite for the designer/developer audience, who would then have to write the version for the end-user
• Figure out where 'end-user' facing material could/should live on the site (if at all)

Personally I feel that this kind of guide is absolutely essential to get more people to self-custody.

I'll ignore your detailed comments for now until the audience for this page, and it's place on the site has been agreed.

[pavlenex]

@danielnordh I didn't know it's deliberate, do we expect end-users to visit the design guide and get an education, or should we leave that to other projects? I'm just curious, it's a good document, I just don't feel it's fitting well with the rest of the content that addresses the app creates instead of the end users.

[GBKS]

To weigh in on whether this fits into the guide, I think the content is interesting to both end-users and product-builders. Even us relatively experienced Bitcoiners are struggling with this issue. The fact that several sites exist (Glacier, Yeti, 10x) that also try to tackle this reinforces that this is a need.

I suggest turning this into a mini-project with its own microsite, possible combined with the backup builder concept (add an inheritance sheet also). End-users can use this to help them sort out their backup needs. Designers can learn by studying the different solutions. Product builders can link to this instead of having to create their own guide.

A dedicated microsite would allow for crowd-sourced contributions and localization, making it more widely useful.

We could also turn this into a larger effort that we could call the "Bitcoin User Guide". It could cover more tips (like avoiding address reuse) that are independent of which software or hardware is being used. It would fit with our larger goal of making Bitcoin easier to use.

[pavlenex]

@GBKS That's a good idea, but we should talk and consider if too much watering down the Design Guide with too many side-projects is beneficial. At the end of the day, we do want our target audience to be able to find stuff easily, if we keep "side-project" everything, it may influence the ease of navigation and the quality of content in the guide.

This is more general thought though, not specifically 1:1 related to this PR. ^

[GBKS]

Might be a good topic for the "Discussion" page.

[danielnordh]

Capturing thoughts from the sprint planning call:

• Finish up the page, OK to write for end users (preface at the beginning)
• The content can be taken and re-used in a more accessible form for end-user impact (microsites, existing user-facing sites etc.)
• Consider whether page makes more sense in Foundations or PKM

[pavlenex]

@danielnordh Do you need any help with this, what's left in your opinion so we can get this one ready for review?

[danielnordh]

I'm planning to wrap this up this week, should be ready by Friday.

[danielnordh]

Due to messed up merge history with this commit I've moved the work over to a fresh PR:
#305

[danielnordh]

PR for issue #139

Adds a page under Private Key Management with a guide to Bitcoin backups.

[pavlenex]

@danielnordh I like the general idea behind this.

I've started doing a bit closer review at first, but I then realized there are some structural issues that I feel we can address here. For starters, this whole section talks to the end-user directly. It doesn't really talk to our target audience, designers/developers. What this should do is teach the target audience how to "teach" or present this to the user, and that's the biggest missing gap to me. Lots of do's and don't actually tell end-user what to do, which felt a bit off.

The structure itself and the suggestions are good (there are some choices I am not sure I agree with ex storing seed in a jar, but that can be ironed out later on.

[danielnordh]

@danielnordh I like the general idea behind this.

I've started doing a bit closer review at first, but I then realized there are some structural issues that I feel we can address here. For starters, this whole section talks to the end-user directly. It doesn't really talk to our target audience, designers/developers. What this should do is teach the target audience how to "teach" or present this to the user, and that's the biggest missing gap to me. Lots of do's and don't actually tell end-user what to do, which felt a bit off.

The structure itself and the suggestions are good (there are some choices I am not sure I agree with ex storing seed in a jar, but that can be ironed out later on.

Agree that this speaks to a different audience, but it was deliberate.
The intention here was to have a guide for end-users that can be a reference.

We could either:

• Rewrite for the designer/developer audience, who would then have to write the version for the end-user
• Figure out where 'end-user' facing material could/should live on the site (if at all)

Personally I feel that this kind of guide is absolutely essential to get more people to self-custody.

I'll ignore your detailed comments for now until the audience for this page, and it's place on the site has been agreed.

[pavlenex]

@danielnordh I didn't know it's deliberate, do we expect end-users to visit the design guide and get an education, or should we leave that to other projects? I'm just curious, it's a good document, I just don't feel it's fitting well with the rest of the content that addresses the app creates instead of the end users.

[GBKS]

To weigh in on whether this fits into the guide, I think the content is interesting to both end-users and product-builders. Even us relatively experienced Bitcoiners are struggling with this issue. The fact that several sites exist (Glacier, Yeti, 10x) that also try to tackle this reinforces that this is a need.

I suggest turning this into a mini-project with its own microsite, possible combined with the backup builder concept (add an inheritance sheet also). End-users can use this to help them sort out their backup needs. Designers can learn by studying the different solutions. Product builders can link to this instead of having to create their own guide.

A dedicated microsite would allow for crowd-sourced contributions and localization, making it more widely useful.

We could also turn this into a larger effort that we could call the "Bitcoin User Guide". It could cover more tips (like avoiding address reuse) that are independent of which software or hardware is being used. It would fit with our larger goal of making Bitcoin easier to use.

[pavlenex]

@GBKS That's a good idea, but we should talk and consider if too much watering down the Design Guide with too many side-projects is beneficial. At the end of the day, we do want our target audience to be able to find stuff easily, if we keep "side-project" everything, it may influence the ease of navigation and the quality of content in the guide.

This is more general thought though, not specifically 1:1 related to this PR. ^

[GBKS]

Might be a good topic for the "Discussion" page.

[danielnordh]

Capturing thoughts from the sprint planning call:

• Finish up the page, OK to write for end users (preface at the beginning)
• The content can be taken and re-used in a more accessible form for end-user impact (microsites, existing user-facing sites etc.)
• Consider whether page makes more sense in Foundations or PKM

[pavlenex]

@danielnordh Do you need any help with this, what's left in your opinion so we can get this one ready for review?

[danielnordh]

I'm planning to wrap this up this week, should be ready by Friday.

[danielnordh]

Due to messed up merge history with this commit I've moved the work over to a fresh PR:
#305

[danielnordh]

PR for issue #139

Adds a page under Private Key Management with a guide to Bitcoin backups.

[pavlenex]

@danielnordh I like the general idea behind this.

I've started doing a bit closer review at first, but I then realized there are some structural issues that I feel we can address here. For starters, this whole section talks to the end-user directly. It doesn't really talk to our target audience, designers/developers. What this should do is teach the target audience how to "teach" or present this to the user, and that's the biggest missing gap to me. Lots of do's and don't actually tell end-user what to do, which felt a bit off.

The structure itself and the suggestions are good (there are some choices I am not sure I agree with ex storing seed in a jar, but that can be ironed out later on.

[danielnordh]

@danielnordh I like the general idea behind this.

I've started doing a bit closer review at first, but I then realized there are some structural issues that I feel we can address here. For starters, this whole section talks to the end-user directly. It doesn't really talk to our target audience, designers/developers. What this should do is teach the target audience how to "teach" or present this to the user, and that's the biggest missing gap to me. Lots of do's and don't actually tell end-user what to do, which felt a bit off.

The structure itself and the suggestions are good (there are some choices I am not sure I agree with ex storing seed in a jar, but that can be ironed out later on.

Agree that this speaks to a different audience, but it was deliberate.
The intention here was to have a guide for end-users that can be a reference.

We could either:

• Rewrite for the designer/developer audience, who would then have to write the version for the end-user
• Figure out where 'end-user' facing material could/should live on the site (if at all)

Personally I feel that this kind of guide is absolutely essential to get more people to self-custody.

I'll ignore your detailed comments for now until the audience for this page, and it's place on the site has been agreed.

[pavlenex]

@danielnordh I didn't know it's deliberate, do we expect end-users to visit the design guide and get an education, or should we leave that to other projects? I'm just curious, it's a good document, I just don't feel it's fitting well with the rest of the content that addresses the app creates instead of the end users.

[GBKS]

To weigh in on whether this fits into the guide, I think the content is interesting to both end-users and product-builders. Even us relatively experienced Bitcoiners are struggling with this issue. The fact that several sites exist (Glacier, Yeti, 10x) that also try to tackle this reinforces that this is a need.

I suggest turning this into a mini-project with its own microsite, possible combined with the backup builder concept (add an inheritance sheet also). End-users can use this to help them sort out their backup needs. Designers can learn by studying the different solutions. Product builders can link to this instead of having to create their own guide.

A dedicated microsite would allow for crowd-sourced contributions and localization, making it more widely useful.

We could also turn this into a larger effort that we could call the "Bitcoin User Guide". It could cover more tips (like avoiding address reuse) that are independent of which software or hardware is being used. It would fit with our larger goal of making Bitcoin easier to use.

[pavlenex]

@GBKS That's a good idea, but we should talk and consider if too much watering down the Design Guide with too many side-projects is beneficial. At the end of the day, we do want our target audience to be able to find stuff easily, if we keep "side-project" everything, it may influence the ease of navigation and the quality of content in the guide.

This is more general thought though, not specifically 1:1 related to this PR. ^

[GBKS]

Might be a good topic for the "Discussion" page.

[danielnordh]

Capturing thoughts from the sprint planning call:

• Finish up the page, OK to write for end users (preface at the beginning)
• The content can be taken and re-used in a more accessible form for end-user impact (microsites, existing user-facing sites etc.)
• Consider whether page makes more sense in Foundations or PKM

[pavlenex]

@danielnordh Do you need any help with this, what's left in your opinion so we can get this one ready for review?

[danielnordh]

I'm planning to wrap this up this week, should be ready by Friday.

[danielnordh]

Due to messed up merge history with this commit I've moved the work over to a fresh PR:
#305

[danielnordh]

PR for issue #139

Adds a page under Private Key Management with a guide to Bitcoin backups.

[pavlenex]

@danielnordh I like the general idea behind this.

I've started doing a bit closer review at first, but I then realized there are some structural issues that I feel we can address here. For starters, this whole section talks to the end-user directly. It doesn't really talk to our target audience, designers/developers. What this should do is teach the target audience how to "teach" or present this to the user, and that's the biggest missing gap to me. Lots of do's and don't actually tell end-user what to do, which felt a bit off.

The structure itself and the suggestions are good (there are some choices I am not sure I agree with ex storing seed in a jar, but that can be ironed out later on.

[danielnordh]

@danielnordh I like the general idea behind this.

I've started doing a bit closer review at first, but I then realized there are some structural issues that I feel we can address here. For starters, this whole section talks to the end-user directly. It doesn't really talk to our target audience, designers/developers. What this should do is teach the target audience how to "teach" or present this to the user, and that's the biggest missing gap to me. Lots of do's and don't actually tell end-user what to do, which felt a bit off.

The structure itself and the suggestions are good (there are some choices I am not sure I agree with ex storing seed in a jar, but that can be ironed out later on.

Agree that this speaks to a different audience, but it was deliberate.
The intention here was to have a guide for end-users that can be a reference.

We could either:

• Rewrite for the designer/developer audience, who would then have to write the version for the end-user
• Figure out where 'end-user' facing material could/should live on the site (if at all)

Personally I feel that this kind of guide is absolutely essential to get more people to self-custody.

I'll ignore your detailed comments for now until the audience for this page, and it's place on the site has been agreed.

[pavlenex]

@danielnordh I didn't know it's deliberate, do we expect end-users to visit the design guide and get an education, or should we leave that to other projects? I'm just curious, it's a good document, I just don't feel it's fitting well with the rest of the content that addresses the app creates instead of the end users.

[GBKS]

To weigh in on whether this fits into the guide, I think the content is interesting to both end-users and product-builders. Even us relatively experienced Bitcoiners are struggling with this issue. The fact that several sites exist (Glacier, Yeti, 10x) that also try to tackle this reinforces that this is a need.

I suggest turning this into a mini-project with its own microsite, possible combined with the backup builder concept (add an inheritance sheet also). End-users can use this to help them sort out their backup needs. Designers can learn by studying the different solutions. Product builders can link to this instead of having to create their own guide.

A dedicated microsite would allow for crowd-sourced contributions and localization, making it more widely useful.

We could also turn this into a larger effort that we could call the "Bitcoin User Guide". It could cover more tips (like avoiding address reuse) that are independent of which software or hardware is being used. It would fit with our larger goal of making Bitcoin easier to use.

[pavlenex]

@GBKS That's a good idea, but we should talk and consider if too much watering down the Design Guide with too many side-projects is beneficial. At the end of the day, we do want our target audience to be able to find stuff easily, if we keep "side-project" everything, it may influence the ease of navigation and the quality of content in the guide.

This is more general thought though, not specifically 1:1 related to this PR. ^

[GBKS]

Might be a good topic for the "Discussion" page.

[danielnordh]

Capturing thoughts from the sprint planning call:

• Finish up the page, OK to write for end users (preface at the beginning)
• The content can be taken and re-used in a more accessible form for end-user impact (microsites, existing user-facing sites etc.)
• Consider whether page makes more sense in Foundations or PKM

[pavlenex]

@danielnordh Do you need any help with this, what's left in your opinion so we can get this one ready for review?

[danielnordh]

I'm planning to wrap this up this week, should be ready by Friday.

[danielnordh]

Due to messed up merge history with this commit I've moved the work over to a fresh PR:
#305

[danielnordh]

PR for issue #139

Adds a page under Private Key Management with a guide to Bitcoin backups.

[pavlenex]

@danielnordh I like the general idea behind this.

I've started doing a bit closer review at first, but I then realized there are some structural issues that I feel we can address here. For starters, this whole section talks to the end-user directly. It doesn't really talk to our target audience, designers/developers. What this should do is teach the target audience how to "teach" or present this to the user, and that's the biggest missing gap to me. Lots of do's and don't actually tell end-user what to do, which felt a bit off.

The structure itself and the suggestions are good (there are some choices I am not sure I agree with ex storing seed in a jar, but that can be ironed out later on.

[danielnordh]

@danielnordh I like the general idea behind this.

I've started doing a bit closer review at first, but I then realized there are some structural issues that I feel we can address here. For starters, this whole section talks to the end-user directly. It doesn't really talk to our target audience, designers/developers. What this should do is teach the target audience how to "teach" or present this to the user, and that's the biggest missing gap to me. Lots of do's and don't actually tell end-user what to do, which felt a bit off.

The structure itself and the suggestions are good (there are some choices I am not sure I agree with ex storing seed in a jar, but that can be ironed out later on.

Agree that this speaks to a different audience, but it was deliberate.
The intention here was to have a guide for end-users that can be a reference.

We could either:

• Rewrite for the designer/developer audience, who would then have to write the version for the end-user
• Figure out where 'end-user' facing material could/should live on the site (if at all)

Personally I feel that this kind of guide is absolutely essential to get more people to self-custody.

I'll ignore your detailed comments for now until the audience for this page, and it's place on the site has been agreed.

[pavlenex]

@danielnordh I didn't know it's deliberate, do we expect end-users to visit the design guide and get an education, or should we leave that to other projects? I'm just curious, it's a good document, I just don't feel it's fitting well with the rest of the content that addresses the app creates instead of the end users.

[GBKS]

To weigh in on whether this fits into the guide, I think the content is interesting to both end-users and product-builders. Even us relatively experienced Bitcoiners are struggling with this issue. The fact that several sites exist (Glacier, Yeti, 10x) that also try to tackle this reinforces that this is a need.

I suggest turning this into a mini-project with its own microsite, possible combined with the backup builder concept (add an inheritance sheet also). End-users can use this to help them sort out their backup needs. Designers can learn by studying the different solutions. Product builders can link to this instead of having to create their own guide.

A dedicated microsite would allow for crowd-sourced contributions and localization, making it more widely useful.

We could also turn this into a larger effort that we could call the "Bitcoin User Guide". It could cover more tips (like avoiding address reuse) that are independent of which software or hardware is being used. It would fit with our larger goal of making Bitcoin easier to use.

[pavlenex]

@GBKS That's a good idea, but we should talk and consider if too much watering down the Design Guide with too many side-projects is beneficial. At the end of the day, we do want our target audience to be able to find stuff easily, if we keep "side-project" everything, it may influence the ease of navigation and the quality of content in the guide.

This is more general thought though, not specifically 1:1 related to this PR. ^

[GBKS]

Might be a good topic for the "Discussion" page.

[danielnordh]

Capturing thoughts from the sprint planning call:

• Finish up the page, OK to write for end users (preface at the beginning)
• The content can be taken and re-used in a more accessible form for end-user impact (microsites, existing user-facing sites etc.)
• Consider whether page makes more sense in Foundations or PKM

[pavlenex]

@danielnordh Do you need any help with this, what's left in your opinion so we can get this one ready for review?

[danielnordh]

I'm planning to wrap this up this week, should be ready by Friday.

[danielnordh]

Due to messed up merge history with this commit I've moved the work over to a fresh PR:
#305

[danielnordh]

PR for issue #139

Adds a page under Private Key Management with a guide to Bitcoin backups.

[pavlenex]

@danielnordh I like the general idea behind this.

I've started doing a bit closer review at first, but I then realized there are some structural issues that I feel we can address here. For starters, this whole section talks to the end-user directly. It doesn't really talk to our target audience, designers/developers. What this should do is teach the target audience how to "teach" or present this to the user, and that's the biggest missing gap to me. Lots of do's and don't actually tell end-user what to do, which felt a bit off.

The structure itself and the suggestions are good (there are some choices I am not sure I agree with ex storing seed in a jar, but that can be ironed out later on.

[danielnordh]

@danielnordh I like the general idea behind this.

I've started doing a bit closer review at first, but I then realized there are some structural issues that I feel we can address here. For starters, this whole section talks to the end-user directly. It doesn't really talk to our target audience, designers/developers. What this should do is teach the target audience how to "teach" or present this to the user, and that's the biggest missing gap to me. Lots of do's and don't actually tell end-user what to do, which felt a bit off.

The structure itself and the suggestions are good (there are some choices I am not sure I agree with ex storing seed in a jar, but that can be ironed out later on.

Agree that this speaks to a different audience, but it was deliberate.
The intention here was to have a guide for end-users that can be a reference.

We could either:

• Rewrite for the designer/developer audience, who would then have to write the version for the end-user
• Figure out where 'end-user' facing material could/should live on the site (if at all)

Personally I feel that this kind of guide is absolutely essential to get more people to self-custody.

I'll ignore your detailed comments for now until the audience for this page, and it's place on the site has been agreed.

[pavlenex]

@danielnordh I didn't know it's deliberate, do we expect end-users to visit the design guide and get an education, or should we leave that to other projects? I'm just curious, it's a good document, I just don't feel it's fitting well with the rest of the content that addresses the app creates instead of the end users.

[GBKS]

To weigh in on whether this fits into the guide, I think the content is interesting to both end-users and product-builders. Even us relatively experienced Bitcoiners are struggling with this issue. The fact that several sites exist (Glacier, Yeti, 10x) that also try to tackle this reinforces that this is a need.

I suggest turning this into a mini-project with its own microsite, possible combined with the backup builder concept (add an inheritance sheet also). End-users can use this to help them sort out their backup needs. Designers can learn by studying the different solutions. Product builders can link to this instead of having to create their own guide.

A dedicated microsite would allow for crowd-sourced contributions and localization, making it more widely useful.

We could also turn this into a larger effort that we could call the "Bitcoin User Guide". It could cover more tips (like avoiding address reuse) that are independent of which software or hardware is being used. It would fit with our larger goal of making Bitcoin easier to use.

[pavlenex]

@GBKS That's a good idea, but we should talk and consider if too much watering down the Design Guide with too many side-projects is beneficial. At the end of the day, we do want our target audience to be able to find stuff easily, if we keep "side-project" everything, it may influence the ease of navigation and the quality of content in the guide.

This is more general thought though, not specifically 1:1 related to this PR. ^

[GBKS]

Might be a good topic for the "Discussion" page.

[danielnordh]

Capturing thoughts from the sprint planning call:

• Finish up the page, OK to write for end users (preface at the beginning)
• The content can be taken and re-used in a more accessible form for end-user impact (microsites, existing user-facing sites etc.)
• Consider whether page makes more sense in Foundations or PKM

[pavlenex]

@danielnordh Do you need any help with this, what's left in your opinion so we can get this one ready for review?

[danielnordh]

I'm planning to wrap this up this week, should be ready by Friday.

[danielnordh]

Due to messed up merge history with this commit I've moved the work over to a fresh PR:
#305