Yep, that's the idea 
, the usual issue (or non-issue) with knowledgeable people like rextended or Amm0 (or you as the Author) testing this kind of stuff is that they cannot usually see the thingy with the eyes of a newbie (which is actually the more likely kind of user) so making it easier to test allows for more "basic" feedback that translates to easier to use that allows for more ...
The undo... do not undo...
@cieplik206 the design is very cool, I love it! Thanks for sharing it and making it easily available
1 Like
Don't you think it's time to do something easy to do about it, without having to go through branding and all that entails?
Thank you.
1 Like
What is not easy about this way? The author has done so much to make it easier and more transparent, yet you still complain
It's because it's not updatable nor transparent as to the HTML/JS sources. Branding package are compress/signed and the added files are not visible in Files.
But I'm not the only one complaining.
Simply make the home page easily replaceable without having to worry about a branding package that has some hidden surprises that are activated upon installation...
If people get used to putting "branding" packages, how long do you think it will take before someone takes advantage of it???... (I'm not talking about this topic)
Evil maids at the distributor/warehouse? 
I really like the direction this dashboard is going. As I have no use for WebFig, this looks like a perfect substitution. Does this custom branding package remove the default webfig files?
@infabo - Thanks for the interest! To answer your question: The DPK doesn't actually remove WebFig files - it replaces the login page routing. WebFig remains physically present on the router
but becomes inaccessible through the web interface. There is technically a way to make both TikView and WebFig work side-by-side, but I haven't implemented this yet as I'm not sure it's the
right direction.
@rextended @normis @Amm0 - I appreciate all the feedback and healthy discussion! Let me clarify the intended use case:
Target Audience: TikView wasn't designed for general public use per se. I had technical professionals in mind - ISPs, service integrators, and network administrators who provide MikroTik
routers to their customers. The idea is they can offer their end users a simplified, modern dashboard for basic insights while maintaining full control themselves.
On Trust & Transparency: I understand the security concerns about DPK packages. That's precisely why:
- The complete source code is on GitHub
- Build instructions are provided so you can compile it yourself
- The "undo" package was created for easy removal
My stance is simple: If you don't trust it, don't use it. That's perfectly valid and I respect that position.
Why Branding Package?: For my use case (providing branded interfaces to customers), the DPK approach is actually ideal because:
- It survives factory resets
- Works offline
- No external dependencies
- Integrated into the router itself
I recognize this approach has limitations and isn't perfect for everyone. The community's feedback has been invaluable in understanding different perspectives and use cases. Perhaps MikroTik
will eventually provide better options for custom web interfaces, but until then, this is the solution that works for my specific needs.
Thanks again for the constructive discussion - it's helping make the project better! 
I don't like complaining without providing solutions.
Anyone who does that seems like an idiot to me, so I don't like being one.
I'm a bit stuck now, but keep developing and I'll help you fix it...
In the meantime, I'm providing you with the original MikroTik logo, which doesn't include the version text, copyright or URL...
MMM MMM KKK TTTTTTTTTTT KKK
MMMM MMMM KKK TTTTTTTTTTT KKK
MMM MMMM MMM III KKK KKK RRRRRR OOOOOO TTT III KKK KKK
MMM MM MMM III KKKKK RRR RRR OOO OOO TTT III KKKKK
MMM MMM III KKK KKK RRRRRR OOO OOO TTT III KKK KKK
MMM MMM III KKK KKK RRR RRR OOOOOO TTT III KKK KKK
Thanks, I have updated undo.dpk. (not tested it)
What I really want to add to Tikview is a good interface for showing wifi registered devices, but all of my MikroTik gear is either too old to run v7 or doesn’t have Wi-Fi interfaces at all.
Would it be possible to enable by anyone a read-only access on a MikroTik that has:
- A legacy radio without CAPsMAN
- A legacy radio with CAPsMAN
- Wave2 radios with Wi-Fi (centralized and/or decentralized config)
so that I would be able to grab real API JSONs via the REST API?
Cannot of course say if it would be the right direction, but as long as it is possible as an option, it would probably contribute to more people testing it (of course only if it is not too complex to implement).
It's there, it's there, then we'll talk about it and make it happen as soon as I have more "practical" time...
@normis since you stoped around got a question for you.
Do you have on roadmap a SSE/HTTPStream for rest api ?
I put a feature request ticket (" REST API - POST should allow a .../listen using WebSockets [or SSE] protocol", SUP-126622), starting in 2023, for exactly this — server-sent events [SSE] or WebSockets... since the problem is you have to poll for status today.
I followed up again this year, both Cisco went the SSE route for their dashboard api & the removed/re-added "Status" page in WebFig. @denissMT did suggest:
There is an internal feature request in place, however, no promises yet.
and other commentary in JIRA suggests the "how to avoid polling" is at least on the radar.
1 Like
DDG says it's some kind of python library on the client side, not for the server side. Clarify what you mean?
great works!!!
I really like it and hope you keep on developing!
Try again push is now completed to web