Why now

The main reason is of course regulation. Article 50 of the EU AI Act has applied since August 2, 2026. It requires AI providers to mark generated content in a machine-readable way, so it can be decteted more easily. This includes any company with EU users, not just European ones. Fines can reach €15M or 3% of global turnover. Similary, California’s SB 942 takes effect on the same date and requires hidden disclosures from providers with more than a million users in the state. Because two major markets have the same rule starting on the same day, AI providers now have to comply.

How it works

A language model guesses one word at a time when writing and it often has more than one equally good options for the next word. After “The weather today was cold and…”, both “overcast” and “grey” fit. Normally a random number generator picks between them.

Claude uses SynthID-Text, a method developed by Google DeepMind and it replaces that random pick with a rule based system that uses secret key and the words that came just before. With a small text it’s not as efficient but with over hundreds of words, though, it builds a statistical pattern that a detector with the key can measure.

According to Anthropic:

• Quality doesn’t change. The model only chooses among options it already rated as equally good and Google DeepMind’s testing found no significant difference in user ratings.
• Users pay nothing extra. The watermark adds no extra tokens.
• The watermark contains nothing about the user. It can’t be traced to a person, an organization or a chat.

Code gets very little watermarking, since there’s rarely a choice between equally good options. Images get C2PA metadata instead: a signed record that Claude was involved but a screenshot or re-save can strip it and Anthropic is also adding watermarks to older Claude models over the coming months.

What it can’t do

• Short or factual text gives a weak signal, because there are few word choices to use the pattern.
• Editing weakens it. Copy paste keeps the watermark of couse but heavy editing weakens it and a full rewrite can even remove it.
• It can’t show authorship. It can’t tell whether Claude wrote a piece or only enhanced it.
• Common AI detectors can’t read it. GPTZero and Turnitin are still guessing from writing style. The real detection API is in private preview for regulators, researchers, media, schools and fact-checkers.

What to do about it

If you’re a freelancer or run a studio that uses AI in client work, stop treating AI use as something to hide. Write a clear disclosure policy that says when and how clients learn AI was involved and put it in your contracts. Now that AI involvement can be checked, being open about it costs you nothing and getting caught hiding it can cost a lot.

Watermarks won’t end misinformation and a determined person can still get around them. But they change the default: most AI text will now carry a quiet signal of where it came from.

Sources:

• https://www.layer3labs.io/guides/ai-watermarking
• https://www.anthropic.com/news/claude-text-watermark

The post Your AI Text Now Has a Hidden Fingerprint appeared first on Mobile USTP MKL.

Why not Figma or Canva?

All three big design tools now have AI. Figma puts it inside a professional canvas and coding agents can even design directly in your files. Canva AI 2.0 creates layered, editable designs from a conversation. It’s great for marketing material, but it isn’t built for app UI.

For OnTime, the question was simple: who is the designer on this project? I’m a solo developer. I had a design system in Figma to build on but I wanted something new. Claude Design can read images and design or even codebases and extract its colors, typography and components, so it was an easy choice.

The start

V1 already had parts I wanted to keep, like the week calendar with drag-to-create entries and the live recorder. A new look wasn’t the only reason I decided to design a new UI. It also needed to fit a much bigger app around that core: workspaces, roles, invoices and bank reconciliation.

So I didn’t start with a blank prompt but I gave Claude Design my previous design and it built a design system from them. Then I asked for the new screens. It made the iteration faster but it also needed a lot of help finding the correct design. It was by far not a single-prompt-execution and it took a lot of trial and error to get to a useable state.

• Overview: V1’s overview had bar and pie charts. For V2, the overview got more animated stat cards, an activity heatmap and a project split.
• Calendar: This screen changed the least. The work here was mostly styling it to the new design and adding a new entry design so it’s more compatible for multi-user support.
• Table pages: The table pages consist (well) just pages, so the main thing was to add the new design layout and archivable entries with a switch.
• Notifications: Funnily enough, this page was the hardest to design because the plain table design didn’t feel right. I decided to use cards for each notification with views for read and unread messages.
• Invoices and payment review: These screens were new, so there was nothing from V1 to copy. But since it was also one of the last pages I got to, it was easier to find a fitting design.

From design to code

The implementation took the longest to do because I rebuilt everything by hand in React. Claude Design lets you export your website as code but without any framework. I could’ve moved around it to let Claude generate everything but I wanted to do the programming side on my own. The mobile shell sits behind its own build flag in the app so switching the flag for testing on desktop was easy to do.

What worked, what didn’t

What worked:

• Exploring was nearly free. I tried a lot of directions for the design and the different pages before settling on one.
• The design system stayed mostly consistent across screens without me policing it.

What didn’t:

• The spacing not always stayed consistent.
• Not explaining your idea in detail leads to disappointing results.
• Design may look generic.

Takeaway

For a solo developer, the design phase used to mean switching tools: design in Figma, then translate it into code by hand. With Claude Design, but now you can make Claude do the heavy lifting. Even though I decided to implement the design myself in code, it designing of the actual website was way faster and I was able to test a lot of different directions. The decisions stayed with me: what gets attention first, what stays from V1, what a finished page should look like. Claude did the designing and I made the design decisions.

The post Designing OnTime V2 with Claude Design appeared first on Mobile USTP MKL.

V2 lives in a new repository, but it is of course built on Version one. The tracker is still at its core and around it, OnTime now handles teams, invoices and payments.

What changed

In V1, one person tracked their own time but in V2, everything happens inside workspaces. A workspace can consist of just you or a whole team and every member has one of four roles: owner, admin, manager or member.

But the basics are of course still there: a timer, manual entries and clients, projects and tasks with their own detail pages. The calendar is now shared and even updates live across devices. Projects can have budgets that send a notification when they cross a threshold. The whole app is in English and German and on mobile it works offline thanks to a persisted query cache.

Invoices and payments

This is where V2 changes the most from its previous version. Billable time becomes an invoice and when you send it, an Edge Function renders it as a PDF and freezes it. If you edit the underlying time entries later, the document the client already received doesn’t change.

Additionally, OnTime connects to your bank through Enable Banking. The connection is read-only by design and you bring your own credentials, which are stored encrypted in Supabase Vault. A scheduled pg_cron job pulls in transactions and matches them against open invoices. When a match is confident, the invoice is marked paid automatically. Everything else waits in a queue for one-click review.

Database changes

V1’s database only had to serve one person tracking their own hours. V2 needed a real data model, so I didn’t patch the old schema and started from the start.

As said before, Everything belongs to a workspace: Clients, projects, tasks, time entries and invoices all hang off a workspace and every row knows which workspace it belongs to. That one change is what makes teams possible. It’s also what the security model is built on.

Also, every table has row-level security policies that check the caller’s workspace and role before returning a single row. Views run with security_invoker, so they apply the permissions of the person querying them instead of quietly bypassing them. Owners, admins, managers and members all hit the same tables and get different answers. Since the frontend isn’t trusted to enforce any of this, pgTAP suites test the rules against a real database.

Another security measure was to add a timestamp to entries when they get deleted. Now they are moved to a trash view, where they can be restored. A pg_cron job purges them for good once they’ve been in the trash long enough, so nobody has to clean up by hand.

An invoice can’t point at time entries and hourly rates, because those can change or be edited. When an invoice is sent, it stores a JSONB snapshot of everything it was built from and the PDF is frozen alongside it. Rates also keep a history, so billing a project in March uses March’s rate even if it went up in June. Invoice numbers are generated per workspace and restart each year.

pg_cron also triggers the bank sync so that transactions come in on a schedule, get matched against open invoices and confident matches mark the invoice as paid. The bank credentials never sit in a plain column and are encrypted in Supabase Vault.

The shared calendar and the notifications subscribe to database changes through Supabase Realtime. When someone stops a timer on their phone, the entry shows up on everyone else’s desktop without a refresh.

Testing

Tests run in three layers:

• Vitest for units and components
• Playwright end-to-end tests against a preview build
• pgTAP for the security rules

Unit and end-to-end coverage are combined into one number and uploaded to Codecov on every CI run. Right now I have about 40% coverage but that will still be improved in later versions.

The post OnTime V2 appeared first on Mobile USTP MKL.

The goal

Our goal was to create a prototype that plays media that isn’t just linear. We wanted a way to inject logic, like quizzes, info overlays, and decision points, directly into the media timeline. It doesn’t matter if it’s a certain position on a text or a specific time in a video.

To make this work across different platforms, we first had to define a standardized data structure. This led to the development of the WIMP format.

Another important part of this project is a media player that is highly mobile optimized and easy to understand, so that even a five year old can experience a WIMP interactive medium.

The project is split into two distinct layers: the data standard and the playback engine.

Architecture

1. The Format

Before building the player, we needed a predictable way to describe the media content. For this, we had to design a format that incooperates everything a WIMP user needs and will need in the future. This forward thinking and upgradeability of our format was one of the main challenges that we faced during this Wild Week. We ended up with an open-format JSON schema that defines a graph of “media nodes.” Each node can contain:

• Timed Events: Quizzes, info texts, external links and more that can be triggered at specific timestamps.
• Choice Events: Branching points that tell the player which media node to load next.

By publishing this as an NPM package, we integrated a validator directly into the workflow, ensuring that any content loaded by the player is structurally sound and free of dead ends.

Here’s an example format:

{
    "version_number": "0.0.1",
    "format_type": "wimp",
    "meta_data": {
        "id": "7f6b6d2d-8fb7-4bd4-9f2a-5a1e2d7c6b42",
        "created_at": "2026-04-23T00:00:00+02:00",
        "updated_at": "2026-04-23T00:00:00+02:00",
        "author": "Melanie Maier",
        "title": "What If Dinosaurs Still Lived Today?",
        "start_media_id": "dinosaur_intro_text",
        "description": "An interactive documentary exploring the hypothetical scenario of dinosaurs still existing in the modern world.",
        "tags": [
            "dinosaurs",
            "interactive documentary",
            "hypothetical scenario",
            "modern world"
        ]
    },
    "media": [{
            "id": "dinosaur_intro_text",
            "title": "Introduction",
            "type": "text",
            "resource_link": "https://wimplayer.media.ustp.at/media.php?name=dinosaurs_intro.html",
            "timeline_events": [{
                "type": "choice",
                "title": "Do you want hear about dinosaurs?",
                "position": {
                    "type": "seconds",
                    "value": 0
                },
                "event_context": {
                    "choices": [{
                        "label": "Start the journey",
                        "next_media": "dinosaur_audio1"
                    }]
                }
            }]
        },
        {
            "id": "dinosaur_audio1",
            "title": "Audio 1",
            "type": "audio",
            "resource_link": "https://wimplayer.media.ustp.at/media.php?name=dinosaur_1.mp3",
            "timeline_events": [{
                    "type": "quiz",
                    "title": "What would be the most likely immediate response from modern states once the existence of large living dinosaurs was confirmed?",
                    "position": {
                        "type": "seconds",
                        "value": 5
                    },
                    "event_context": {
                        "answers": [{
                                "label": "Opening all affected regions to tourism",
                                "is_correct": false,
                                "feedback": ""
                            },
                            {
                                "label": "Establishing exclusion zones and interdisciplinary crisis task forces",
                                "is_correct": true,
                                "feedback": ""
                            },
                            {
                                "label": "Immediately classifying all species as domesticated animals",
                                "is_correct": false,
                                "feedback": ""
                            },
                            {
                                "label": "Suspending all ongoing scientific research",
                                "is_correct": false,
                                "feedback": ""
                            }
                        ]
                    }
                },
                {
                    "type": "quiz",
                    "title": "Why would the discovery of living dinosaurs be more than just a zoological sensation?",
                    "position": {
                        "type": "seconds",
                        "value": 30
                    },
                    "event_context": {
                        "answers": [{
                                "label": "Because it would automatically replace all existing animal species",
                                "is_correct": false,
                                "feedback": ""
                            },
                            {
                                "label": "Because modern cities are already designed for giant reptiles ",
                                "is_correct": false,
                                "feedback": ""
                            }, {
                                "label": "Because it would challenge long-held assumptions about ecology, history, and risk planning",
                                "is_correct": true,
                                "feedback": "Still too high. Fast fashion is often discarded quickly."
                            },
                            {
                                "label": "Because dinosaurs could only survive in artificial reserves ",
                                "is_correct": false,
                                "feedback": ""
                            }
                        ]
                    }
                },
                {
                    "type": "choice",
                    "title": "Do you want to hear more about this scenario?",
                    "position": {
                        "type": "seconds",
                        "value": 60
                    },
                    "event_context": {
                        "choices": [{
                            "label": "Yes please",
                            "next_media": "dinosaur_audio2"
                        }]
                    }
                }
            ],
            "description": "Quick cuts of clothing store racks, online shopping scrolls, and factory workers sewing.",
            "media_length": 76
        },
        {
            "id": "dinosaur_audio2",
            "title": "Dinosaur 2",
            "type": "audio",
            "resource_link": "https://wimplayer.media.ustp.at/media.php?name=dinosaur_2.wav",
            "timeline_events": [{
                    "type": "quiz",
                    "title": "Which dinosaur group would likely be the hardest to control in a modern civilization?",
                    "position": {
                        "type": "seconds",
                        "value": 5
                    },
                    "event_context": {
                        "answers": [{
                                "label": "Small to medium-sized, intelligent, highly adaptable predators",
                                "is_correct": true,
                                "feedback": ""
                            },
                            {
                                "label": "Very large, slow-moving herbivores",
                                "is_correct": false,
                                "feedback": ""
                            },
                            {
                                "label": "Flightless species living only in remote areas",
                                "is_correct": false,
                                "feedback": ""
                            },
                            {
                                "label": "Species with strongly territorial but fixed-range behavior",
                                "is_correct": false,
                                "feedback": ""
                            }
                        ]
                    }
                },
                {
                    "type": "quiz",
                    "title": "Which societal conflict would be most likely if humans and dinosaurs had to coexist permanently?",
                    "position": {
                        "type": "seconds",
                        "value": 35
                    },
                    "event_context": {
                        "answers": [{
                                "label": "Whether dinosaurs should be included in school curricula ",
                                "is_correct": false,
                                "feedback": ""
                            },
                            {
                                "label": "The complete abolition of modern infrastructure",
                                "is_correct": false,
                                "feedback": ""
                            },
                            {
                                "label": "A global abandonment of agriculture",
                                "is_correct": false,
                                "feedback": ""
                            },
                            {
                                "label": "A conflict between species protection, public safety, and economic use of land",
                                "is_correct": true,
                                "feedback": ""
                            }
                        ]
                    }
                },
                {
                    "type": "choice",
                    "title": "Do you want to read more?",
                    "position": {
                        "type": "seconds",
                        "value": 55
                    },
                    "event_context": {
                        "choices": [{
                            "label": "Yes please",
                            "next_media": "dinosaur_end_text"
                        }]
                    }
                }
            ],
            "description": "Dinosaur audio",
            "media_length": 59
        },
        {
            "id": "dinosaur_end_text",
            "title": "End",
            "type": "text",
            "resource_link": "https://wimplayer.media.ustp.at/media.php?name=dinosaurs_end.html",
            "timeline_events": []
        }
    ]
}

2. The Frontend: Nuxt & Logic

The player itself is built with Nuxt. We chose Nuxt because its reactive framework is ideal for syncing a video’s progress with dynamic UI overlays.

For this we split our team into 2 departments:

• The UI/UX of the main page and components
• The player with the state machine

Main Page & Components UI/UX

For prototyping and designing our pages and components, we decided on using Figma with Nuxt’s components to help us out. Here are some examples of our pages and components:

State Machine

To manage the complexity of interactive playback, we implemented a state machine. The state machine coordinates:

• Syncing Logic: Monitoring the video’s currentTime to trigger overlays from the WIMP format.
• Interaction States: When a pause: true event occurs, the machine pauses the background media, putting the quiz or choice interface in the foreground.
• Dynamic Media Handling: When a user makes a choice, the machine resolves the next_media ID and updates the Nuxt state to swap the media and move forward in the decission tree.

The post Wild Week – Wyld Interactive Media Player appeared first on Mobile USTP MKL.

Tools and Technologies

To achieve this, I used the most recent version of Android Studio in combination with:

Frontend: Jetpack Compose

When developing apps in Android Studio, the recommended framework is Android’s Jetpack Compose. It is a modern toolkit for building native UIs and simplifies and accelerates UI development on Android.

Backend / Database: Jetpack Room

Jetpack Room is a persistence library introduced as part of the Android Jetpack suite to simplify working with SQLite databases. It provides an abstraction layer over SQLite, allowing more robust database access while still enabling the full power of SQLite.

Translation: ML Kit

With Android Studio’s ML Kit Translation API, users can translate text in over 50 different languages without the need for an internet connection, and it is completely free to use for development.

Project Scope

My goal is to develop an intuitive app that lets users learn new words in different languages.

The app should contain:

• Start Page
  • Before users can begin learning, they need to set a name and their nationality so ML Kit knows which language to translate into.
• Overview of folders and cards
  • Users can create multiple folders with different language settings and visuals. In these folders, they can see their added cards.
• Add folders
  • Adding folders should be easy, and folders should also be easily distinguishable. To achieve this, users can set a name (e.g., German vocabulary), a color, the foreign language (e.g., German), and change the local language if needed (default is the user’s nationality).
• Add cards
  • Adding cards is the most important feature of this app. Users add a new word and have two optional fields for example sentences and tags.
• Automatic translation
  • For ease of use (and to experiment with Android’s APIs), the new word is automatically translated into the user’s language.
• Quiz mode
  • With quiz mode, users can test their skills using three different modes: Random, Bookmarked, and Recall (a list of incorrectly answered cards).

Beyond the Initial Scope

Additionally, I implemented several features that further improve the app’s functionality:

• User edit page: Allows users to edit their name, nationality, and app theme.
• Light and dark mode: Added for additional customization.

Overall, the implementation of this project during my first semester was very successful and involved learning many new technologies. Both frontend and backend are fully implemented and can be further extended in the upcoming semesters.

The post Language Learning App appeared first on Mobile USTP MKL.

This paper discusses recent developments in Simultaneous Localization and Mapping (SLAM) combined with the use of Artificial Intelligence (AI). SLAM makes it possible for robots to build maps of unknown environments while tracking their position, but with traditional methods robots often struggle in dynamic or unstructured settings due to unclear or moving objects. Recent advances in AI and its integration into SLAM address these issues by improving feature extraction, predictive modeling, and adaptability. Convolutional and Graph Convolutional Networks enhance robustness and scalability, while transformer architectures enable efficient trajectory planning. Obstacle detection and avoidance in real-world scenarios are further reinforced by deep reinforcement learning. AI-driven innovations also introduce multi-modal sensor fusion, semantic mapping, enhanced loop closure detection, and collaborative multi-agent frameworks. Comparative studies reveal that AI-enhanced SLAM shows a higher accuracy and robustness across varied scenarios.

The post State of the Art of AI-Enhanced SLAM appeared first on Mobile USTP MKL.

Both platforms promise fast and easy development, built-in authentication, real-time data, and scalable infrastructure. But can they deliver on these promises and when should I use what? Both are valid choices for your next project but they have their differences in some fundamental ways: data modeling, query flexibility, pricing transparency, and how much you can customize as your app grows. Those differences matter, especially once you move beyond a prototype. But first: what is Supabase actually and what can it do?

What is Supabase

Supabase is a serverless, open-source backend platform that is designed to help developers build scalable, high-performance applications with minimal setup. It’s built on top of PostgreSQL, it provides a fully managed, production-ready database along with essential backend features such as authentication, storage, and real-time data without relying on other services. This means that you don’t need to configure or maintain a custom backend server, allowing you to move faster and focus on product development.

As a serverless solution, Supabase handles infrastructure concerns like provisioning, scaling, and security automatically. It also allows the user to get direct access to a powerful SQL database that uses PostgreSQL for structured data modeling, complex queries, joins, and transactions.

With Supabase, you get a managed backend with features like:

• SQL database: PostgreSQL with support for advanced queries, joins, and JSON data.
• Authentication: Secure, built-in user management.
• Realtime updates: Live data synchronization using WebSockets.
• Storage: Easy-to-use storage for files and media.
• Edge functions: Custom serverless functions for handling app logic.

Firebase

Similar to Supabase, Firebase is a backend-as-a-service solution offered by Google, which assists developers in the development of applications without the need for them to handle the infrastructure on their own. Firebase also offers a set of features such as authentication, real-time databases, cloud functions, file storage, and analytics. This solution is designed with the objective of providing ease of use and rapid development.

At the heart of the Firebase platform are the NoSQL databases, namely the Realtime Database and the Cloud Firestore, which organize and store the data in the form of documents and collections, unlike traditional relational databases in the form of tables. Although the NoSQL databases provide a degree of flexibility and ease of development, especially when real-time updates and data access patterns are concerned, handling complex relationships and queries in a scaled-up application might be a challenge.

Supabase takes a different approach to backend development. Like mentioned above, it’s an open-source, serverless framework that centers around PostgreSQL. Supabase offers its features with just one Postgres database.

Supabase vs Firebase

Data model

Firebase supports a NoSQL, document-oriented data structure well-suited for hierarchical or event-oriented data. Supabase supports relational SQL, which provides support for schemas, joins, transactions, and consistency.

Querying and logic

It allows complex queries and business logic to be implemented directly in the database through SQL, constraints, and triggers. Firebase uses more client-side logic and Cloud Functions for complex operations.

Scalability & Control

Whereas Firebase abstracts infrastructure almost completely, which is easy to set up but makes it difficult to customize, Supabase provides more visibility and flexibility, which includes direct database access and the ability to host it on your own infrastructure.

Vendor lock-in

Firebase is highly integrated with Google Cloud. Supabase values portability and focuses on using open standards and tools that make it easy to migrate in and out.

Use Cases

Supabase is well suited for:

• SaaS platforms with relational data and role-based access control
• Data-intensive applications such as analytics dashboards and internal tools
• Projects that require complex queries, transactions, or strong data integrity
• Teams that value open source, portability, and long-term flexibility
  

Firebase is well suited for:

• MVPs and prototypes that need to ship quickly
• Real-time applications like chat, presence, or collaborative tools
• Frontend-heavy apps with simple data relationships
• Teams already invested in the Google Cloud ecosystem
  

Choosing Between Supabase and Firebase

The choice between Supabase and Firebase ultimately depends on how your application handles data and how much control you want over your backend. Firebase is very good at simplicity and speed, while Supabase shines when structure, scalability, and flexibility become more important over time.

Conclusion

Choosing a backend platform is one of the most important decisions you’ll make when starting you fullstack application. It decides not only how fast you’ll progress and deliver your first version, but also how well your application can scale and how complex your data model can become.

Firebase and Supabase are both good options to choose from and remove a lot of the traditional backend complexity. Firebase is good for rapid development, especially for real-time, frontend-driven applications. Supabase, on the other hand, offers a more structured and transparent approach, built around the concept of open-source and PostgreSQL, making it a strong choice for applications that need simple data models and long-term flexibility.

As always, there is no universally “better” option… Only the better fit for your project. If you need to move fast with minimal setup and simple data relationships, Firebase is a solid choice. If your application relies on relational data, complex queries, and future-proof architecture, Supabase provides a powerful and scalable foundation.

Ultimately, the best backend is the one that aligns with your application’s needs today while still supporting where you want it to go tomorrow.

Sources

1. https://bejamas.com/hub/serverless-database/supabase
2. https://somindadhaniya.medium.com/what-is-supabase-the-open-source-firebase-alternative-developers-love-ef63f15e0e48
3. https://www.newline.co/@zaoyang/what-is-supabase-and-how-it-can-replace-your-entire-backend–62b84205
4. https://supabase.com/
5. https://supabase.com/docs/guides/getting-started/architecture
6. https://www.postgresql.org/about/
7. https://firebase.google.com/
8. https://medium.com/firebase-developers/what-is-firebase-the-complete-story-abridged-bcc730c5f2c0

The post What is Supabase and when to use it appeared first on Mobile USTP MKL.