I also want to add tracking for profiles. When that's ready I might include a link to your app there. Would be cool if you could open a specific profile directly with a link like https://gitmentor.app/toniengelhardt.
IMO the benefit of UUIDs over integers is that they can be generated client-side without clashing. But you cannot trust timestamps generated by clients and therefore the order. So what is the benefit over UUID4?
For me the central benefit is that you can create them in a distributed manner and are not reliant on a central system as a single source of truth for creating your identifiers.
I can therefore easily generate a new UUID in a trusted backend service which just accepts the command received from the untrusted client and then forwards the request for asynchronous processing while returning the UUID to the client. This is a typical architecture and the only change is that I can now create UUIDs which may have performance benefits, depending on the data storage technology of my read models.
If you need to create the UUIDs on the client side to support specific requirements such as offline-first, then I would indeed consider adding some reconciliation which replaces the IDs provided by the client-side by new ones generated by a trusted component as soon as synchronizing takes place.
In any case regardless of UUIDv4, v7 or any other format you should not allow the untrusted client to determine the real ID - as long as there is at least one trusted component in the architecture which would take over this role. This should help eliminate a whole set of possible security issues.
The biggest issue to be addressed is monetization IMO. Without monetization there won't be much adoption and without much adoption there won't be much support.
First of all, there is no good guidance about the topic besides some clips about the Digital Goods API and it only works for recent Chrome. How do deal with users that use a different browser or an older version? Is it ok to check if the API is available and if not use Stripe? No info about that... It can be pulled off, but UX will definitely be bad or worse.
Then, there is the problem with complex backend logic and accounting, I have to deal with two scenarios, did the person use Play Billing or Stripe to purchase? What if he used Play Billing and then wants to manage their subscription in the browser or other way around? It would be amazing if either Play Billing could also handle purchases on the web, or if Stripe could detect TWAs and automatically send 15-30% to Google for doing nothing.
Also, what about testing? How can I test my Digital Goods integration if it is only available within an Android app and not in my PWA? Am I supposed to publish an app that points to my dev server?
If Google was really serious about PWAs and Trusted Web Activities I think they should allow developers to use 3rd party payment systems (in TWAs only) until all of the issues are resolved and have solutions, instead of being like "ya we don't know either, you figure it out, but you can't use Stripe". As TWAs are only a miniscule fraction of TWAs in the PlayStore it won't even make a hint of a dent into Google's revenue, but it would allow developers to seriously pursue a PWA solution over a native one and therefore allow Google to see if it is viable and worth putting serious resources into.
Oh really? That's so annoying! I had the issue in the past, it's related to the the mail server from Gandi I suppose. There are no emails sent from this email besides the email confirm, welcome emails, and manual replies to customer requests. Could you mark it as "not spam", that would be very kind.
What's the reason that you don't update your phone to iOS 26?
reply