Draft of the H2 roadmap #18108
Draft of the H2 roadmap #18108
Conversation
Jenkins BuildsClick to see older builds (42)
|
|
The dApp browser is a really nice addition! Let's make it mobile compatible (to use OS webviews instead of the webengine). Another advantage here is that the app could potentially become App Store compliant for MacOs as well. |
docs/roadmap.md
Outdated
|
|
||
| - [Mobile build](https://github.com/status-im/status-desktop/issues/18082) | ||
| - [Dapp Browser](https://github.com/status-im/status-desktop/issues/17970) | ||
| - [Privacy mode](https://github.com/status-im/status-desktop/issues/17619) |
There was a problem hiding this comment.
I would only keep either dapp browser or privacy mode. I expect:
UI modularization
Backend refactor
will still be our priority
There was a problem hiding this comment.
I agree but bringing back the browser shouldn't be that much of an effort
There was a problem hiding this comment.
I agree but bringing back the browser shouldn't be that much of an effort
IMO there will be some effort there. The only way where I think it's not much of an effort is to bring the old browser as it was and maybe to adapt it a little bit. But to have the full potential of this browser we'd need a dapp browser that's using the native webview. What would this bring in:
- mobile support
- App Store compliance for macOs
- we only need to care about chromium on some platforms
docs/roadmap.md
Outdated
| - [QT6 migration](https://github.com/status-im/status-desktop/issues/17622) | ||
| - [Tablet Build](https://github.com/status-im/status-desktop/issues/17941) | ||
| - [Jump to screen (Shell)](https://github.com/status-im/status-desktop/issues/17971) | ||
| - [Memory improvements](https://github.com/status-im/status-go/issues/6544) |
There was a problem hiding this comment.
I would move this one to 2.36
There was a problem hiding this comment.
yes I wouldn't expect us to be able to work on all the rest correctly, maybe smart the mem improvement but aim to finish more in 2.36
docs/roadmap.md
Outdated
|
|
||
| Epic: https://github.com/status-im/status-desktop/issues/18029 | ||
|
|
||
| Estimated release: End of August |
There was a problem hiding this comment.
A bit too tight schedule considering only month after 2.35 and the summer vacations period
jrainville
force-pushed
the
docs/roadmap-H2-2025
branch
from
168782a to
82afd12
Compare
|
Thanks everyone for reviewing. I updated according to your comments. I also improved the graph by adding the milestone releases estimated dates and I added File uploads on Codex to the 2.37 milestone. The last big thing I added is FURPS for all written Epic! Some of them I just grabbed from the issues (kudos @alexjba). The others I generated using an AI from the epic and designs, then I edited them. When this PR is merged, we can link the Epics to the right FURPS document |
| ## Functionality | ||
| - Support navigation to communities, chats, accounts, or dApps through a unified launcher interface. | ||
| - Display recent items with live metadata (e.g., unread count, media preview, timestamps). | ||
| - Order from most recent. When item is clicked, it moves to the top. |
There was a problem hiding this comment.
I already expressed my mixed feelings on the PR related to this behavior: It's a bit annoying to me that the grid order changes each time I click a new item. It's nice to have the most recents on top but then it makes it difficult to find a specific one since it's never at the same position. Maybe we could have the possibility of ordering by recents or not, so user can decide
There was a problem hiding this comment.
Good point. I don't have hard feelings either way.
I hope more people can chime in and express their opinion so we can decide if we drop that functionality
There was a problem hiding this comment.
Yeah... this was requested by Ben; I'm also not very keen on the items jumping around; I'd much rather see them ordered either by "notifications" first, and then alphabet
There was a problem hiding this comment.
As a dev, I kinda like that they order by last used, because in the Local Backup Epic, I can go back to Syncing very easily! 😄
As a user, I'm not sure yet, I haven't put my hands on it my main account yet.
There was a problem hiding this comment.
Also commented it on the PR: Would it make sense to add the Sign out & Quit option in this view too?
There was a problem hiding this comment.
Is is there; want to get rid of it?
docs/FURPS/local-user-backups.md
Outdated
There was a problem hiding this comment.
would be great for message history to be part of this so ux becomes less disastrous
There was a problem hiding this comment.
Message history will be the next step.
We'll start with user data in 2.35 so that we can alleviate the bandwidth usage of Waku and then in 2.36 we'll work on message history 😄
There was a problem hiding this comment.
make sure to include community message history as well. would finally be an end to all the pain. 🙏 once that works and transferring control nodes isnt a death blow anymore ill be all over the app again
There was a problem hiding this comment.
Yes, I think the goal will be to do all messages.
Once I have a draft of the FURPS for that feature, I'll ping you in it!
jrainville
force-pushed
the
docs/roadmap-H2-2025
branch
from
5dd92f8 to
f33592a
Compare
Co-authored-by: Lukáš Tinkl <[email protected]> Co-authored-by: Noelia <[email protected]>
jrainville
force-pushed
the
docs/roadmap-H2-2025
branch
from
a9adeab to
8713fab
Compare
|
also im wondering where keycard shell integration work will be. maybe its estimated to require so little work that it doesnt need to be mentioned here but i hope that assumption is well reasoned. last i heard shell should start shipping in q4 and i think its crucial shell users can immediately be funneled into status wallet since they will probably be most important for revenue and hopefully even formation of communities of snt whales |
Good catch, I forgot to add it. Indeed we will want to support Shell! The Q4 roadmap is a bit hazy because we try to adapt to feedback. I'll add Shell integration! In theory it shouldn't be too hard since it's only about supporting ERC-4527 (knocks on wood) |
Co-authored-by: Lukáš Tinkl <[email protected]>
yeah and also the authentication and signing popups that now ask for pins should recognize when a shell is used so pins and signing actions happen on shell and are properly received and displayed by status wallet. and it should work over usb as well imo since not everyone has webcams available or open at all times for privacy or convenience reasons. |
Please leave comments on what should be moved around, what should be done in later milestones, estimates, etc.
(again pro tip: check in preview mode, especially for the graph)