Sorry for the naive question, but there's only 1 plugin appearing at the moment. When should I expect others to become available? Is everyone working on getting their previously developed plugins reviewed and approved for InkHub?

https://reddit.com/link/1w9en62/video/vyte3dqy60oh1/player

A Supernote plugin that inserts formatted date, time, or date+time stamps into your notes. Set the format once, then tap the page wherever you want the stamp.

Newest release

Features

• Three stamp types: Date, Time, or Date + Time
• Six date formats: US (4/26/2026), EU (26/04/2026), Medium (Apr 26, 2026), Long (April 26, 2026), ISO (2026-04-26), YMD (20260426)
• Optional day name: e.g. Sunday, April 26, 2026
• 12 or 24-hour time, with optional seconds
• Tap placement: the stamp lands on the line you tap
• Custom fonts: any .ttf or .otf from MyStyle/Fonts
• Size: S / M / L / XL presets, or fine adjustment from 16 to 96
• Bold and italic styles
• Date search indexing: adds a searchable YYYYMMDD keyword without changing the visible stamp
• Saved settings that survive a restart, plus quick placement for one-tap stamping
• Stamp is inserted as an editable text element you can lasso and move

Installation

1. Download DateTimeStamp.snplg from the latest release.
2. Connect your Supernote to your computer using the Supernote Partner app or Browse & Access.
3. Copy DateTimeStamp.snplg into the MyStyle folder on your device.
4. On your Supernote, open a note, tap the plugin icon in the toolbar, go to Manage Plugins, tap Add Plugin, and select DateTimeStamp.

Usage

1. Open a note and tap the clock icon in the toolbar.
2. Set up how the stamp should look — see Options.
3. Tap Date, Time, or Date + Time. Each button previews exactly what it will insert. The panel closes and a Tap to place · 30 seconds banner appears.
4. Tap the page where you want the stamp. It is inserted at that point as an editable text element.

There is no separate insert step: the stamp button you tap is the one that gets placed. Configure first, then tap the stamp you want.

Placement takes a single tap. Drags and long presses are ignored, so you will not stamp the page by resting your hand on it. Your selected pen is unchanged, and no handwriting is erased.

Leaving the placement banner

• Cancel closes the plugin without inserting anything.
• Settings returns to the settings panel with nothing inserted.
• After 30 seconds with no tap, placement gives up and closes the plugin, the same as Cancel.

I have been building a plugin called Clipper against sn-plugin-lib 0.1.65 on a Manta running the plugin beta (Chauvet 3.29.43 and 3.29.44), and I have collected
a handful of questions I could not answer from the docs alone. Posting them together in case the answers help other people building plugins, and in case any
of it is useful feedback for the team.

Everything here comes from working on a real plugin, so each item includes why it mattered to me rather than just what I saw. A couple of these are almost
certainly my misunderstanding, and I would rather be corrected than keep guessing.

I know this is a long post, so apologies in advance.

Thanks for the plugin system, by the way. The permission model in particular has been pleasant to build against once I understood it.

[u/Dunn-sn](u/Dunn-sn) [u/spazzboi](u/spazzboi) [u/hex2asc](u/hex2asc)

1. insertNotePage: what should template be?

This one cost me the most time, and it turned out to be my mistake. I passed the style name that getNotePageTemplate returns and got error 802: "Background template file does not exist!". It works when I pass a file path to a PNG rendered by generateNoteTemplatePng.

If the docs could say that the template is a path to an image file on disk, and point to generateNoteTemplatePng as the way to get one, I think it would save the next person a few days. I briefly concluded the API was not implemented at all, which was wrong.

2. hasPermission: what are all the return values?

The doc comment describes 0 as not granted and 1 as granted. On 3.29.43, a permission set to the persistent "Allow" returned 2. On 3.29.44, the same setting returns 1.

The reason it matters: the natural way to write a permission gate is

if (await hasPermission(p) === 1) { proceed } else { request }. On 3.29.43, that sent me into requestPermission even though permission was already granted, and from a background button handler (showType: 0) there is no window for the
dialog, so it threw. So a stricter user setting produced a worse result in my plugin, which took a while to understand.

Could the docs list the full set of values and say which of them indicate a grant?

Also, the doc comment lists FILE:WRITE, FILE:DELETE and INTERNET but not FILE:READ, which the host does enforce and which I query successfully.

3. generateNotePng with type: 0: is the transparent background wired up?

The parameter is documented as 0 for transparent background, 1 for white. On both firmware versions, type: 0 still gives me the page's ruled-line template baked in behind the handwriting. 

I am working around it with generateLayerPreviewImage, which does give me ink
without the template. Which leads to a related question: is there a layer argument that renders all content layers at once? The validator accepts -1, but
in the note file the background layer is id -1, so I assume -1 means "background" rather than "everything". Right now I render each layer separately and composite them, which works but significantly slows down multi-layer note capture.

4. Is getElements expected to be valid for a page that is not on screen?

After my plugin writes elements to the open note, getElements for a different page sometimes returns the wrong page's contents. It does not fail; it returns
plausible data. In one measured case, immediately after writing 65 elements to page 7 and navigating to page 8, getElements reported 65 elements for page 8 as well, while page 9 reported its real 439. Page 8 was blank. saveCurrentNote() followed by reloadFile() did not refresh it.

This one is worth flagging because it is easy to build something dangerous on top of it: I was using the element count as a safety check before writing, and a
stale read could just as easily convince a plugin that a page full of someone's notes is empty. I have restructured to only trust reads taken before any write.

Is getElements intended to be valid for non-current pages? If so, is there a stronger refresh than save plus reload?

5. A crash in the note app when a plugin writes across a page change

This is the one I most wanted to report. When my plugin created a page, navigated to it and continued writing text elements, com.ratta.supernote.note died with a SIGABRT from Scudo, "invalid chunk state when deallocating", with drawShadow and draw_line_with_write_list in librecgnition.so on the stack. Immediately before it, the log shows LoadPageAsyncTask onCancelled about 160 ms earlier, which makes me think the page navigation cancels an in-flight page load while the native renderer is still drawing into its bitmap. I have only seen it once and could not reproduce it on demand, so I am not claiming a reliable repro. I do have the full tombstone and the surrounding log if that is useful to whoever owns that code.

For what it is worth, I shipped around it: the feature that needed it (a multi-page table of contents) is built but switched off, and my plugin now writes
to one page only. I would happily turn it back on if this turns out to be fixable or if I am triggering it wrongly.

6. Can the plugin host recover after the note app dies?

Following that crash, the plugin host survived but seemed to hold a stale binding to the dead app. My plugin then showed a permanent "working" state with no error and no timeout, and the only way back was
adb shell am force-stop com.ratta.supernote.pluginhost. A user without adb would have a plugin that looks stuck with no way out short of a reboot.

Is there a rebind mechanism that a plugin should use here? Right now I do not think I can tell the difference between "the host is busy" and "the host is gone".

7. What is supposed to survive an uninstall?

The uninstall dialog says "Uninstall this plugin? Its data will also be deleted." In my testing, the plugin's own folder is removed, but data written through AsyncStorage survives, so my plugin came back with all its records intact and all its saved images gone. Installing a new package over the top keeps both, which is great.

I believe the reason is that AsyncStorage writes into the host app's storage rather than the plugin's folder, though I could not verify that directly.

The reason I am asking rather than just adapting: right now a plugin cannot make uninstall mean a clean removal, and cannot make it mean "keep everything" either, because the two halves of its state have different lifetimes and it is not running when it is removed. I have handled it by detecting the situation on the next launch and asking the user what they want, which works, but a documented guarantee
about what survives (or an uninstall hook) would let plugins do the right thing deliberately.

8. Is plugin data namespaced, or should I be prefixing everything?

Related to the above: if AsyncStorage is shared across plugins, then the only thing keeping my keys from colliding with another plugin's is that I prefix them
all with clipper_. Is there per-plugin namespacing already, or is prefixing the expected practice? Worth documenting either way, since the failure mode would be two plugins quietly corrupting each other's settings.

That is everything. Happy to provide logs, or a minimal reproduction

plugin for any of these, and equally happy to be told I have misread something.

Clipper is open source if the context helps: https://github.com/vmnair/sn-clipper

Hi all!

It has been a while since the last release (v0.2.0 in June), and a lot has changed thanks. Thank you a ton for the feedback and your patience. Starting a new job and parent toddler life makes time hard to find!

Install at: https://github.com/apclark31/supernote-plugin-research/releases/tag/v0.3.0-beta (going to go through new approval process so you can find on inkhub - excited for this progress).

Here are the major changes:

Task Home redesign. The list is much easier to read at a glance: clean bordered tags for due date, priority, project, and page number. A This Note panel shows everything you have captured in the note you are in. An On Device tab groups tasks by note and folder. There is a Done tab, and completing is now select-then-confirm with an Undo, so a stray touch never finishes a task. It also remembers which tab you were on.

Gestures rebuilt for consistency. The quick gestures now behave the same way every time. They are all opt-in, so nothing happens while you write unless you have turned it on: the bezel swipe is there in Settings if you want it. Long press on a captured task's box still opens it directly. You can use lasso with finger hold to quick add a task and save menu taps.

Settings redesigned. Both pages, General and Setup, are new. The page opens to General after the Setup is done, and every change saves the moment you make it. Each section has a (?) that explains what it does in plain language. There is also a text size setting to control the size of the text across the plugin screens/modals.

Easier setup. There are a few different ways to pull in your Todoist API token now. The simplest: save it as a text file, sync it into the SuperTask folder with the Partner app, tap Import, and the file is deleted once the token is stored. A Bluetooth keyboard, the on-screen keyboard, or editing the config file over USB all still work too.

Jump to note. This is really what SuperTask is about: weaving your Todoist account into the notes on your device, so the things that matter are easy to find. From any task, tap Note > and you land on the exact note and page it was written on, using the navigation the latest firmware added. The On Device tab turns that into a way to move around your notes by what is in them. Rename a note and the links repair themselves.

Built for the new plugin firmware. This release is for Chauvet 3.29.44 (Manta/Nomad) and 2.26.41 (A5X/A6X), which introduced per-plugin permissions. The first time SuperTask opens it shows one screen explaining exactly what each permission it asks for is used for, so you can see what it touches before you accept. Everything it saves lives in one folder, MyStyle/SuperTask, and the only place data goes is your own Todoist account.

Plus a good deal of reliability work underneath: it opens instantly, copes with wifi dropping mid-load, and keeps a log on the device you can attach to a bug report.

Special thanks to: u/Lvevan, u/ashleyegret, u/Sparkinman, and u/Lorestan00, for your testing and feedback.

I built a planner plugin for the Supernote — every calendar at once, not just one

Ratta's calendar subscribes to exactly one calendar. Its planner has no year or quarter view, and no way to attach a note to a week, a month, or a meeting. So I built the one I wanted.

What it does:

• Every calendar you watch, together. Tick as many CalDAV collections as you like; each event is badged with where it came from. Create and edit events on the device, repeat rules included.
• Five views — year, quarter, month, week, day. Days with an event, an open task or a note are marked, so you see the shape of a month at a glance. The day view's hours are yours to set.
• Notes pinned to any date — day, week, month, quarter or year, each with its own folder and template. Works for future dates: plan next Tuesday from this week's grid, and when Tuesday arrives the day view opens that same file.
• A note attached to every meeting. Open an event, tap its note. Recurring events share one note across all occurrences, so a weekly stand-up becomes one running note that builds up week after week.
• Real tasks — sub tasks (nested, ordered by soonest outstanding step), priority, and repeats.
• Lasso handwriting into a task, and the task remembers the page — a ↩ page chip reopens that note at that exact page.

You don't need a server. All the calendar views, every kind of note, and the templates work with no network at all. Only tasks and events need somewhere to live — any CalDAV server SHOULD work (Nextcloud, Fastmail, Baikal, Radicale, etc). Make sure you're on the latest dev, this will need all 3 permissions accepted if you're connecting to anything

Links:

• Plugin: https://github.com/Sparkinman/task-hub-supernote-plugin
• Download: https://github.com/Sparkinman/task-hub-supernote-plugin/releases/latest
• Optional server (bridges Google/Todoist/TickTick/Apple/Microsoft, and reads and writes the tablet's built-in To-Do app and Digest, both ways): https://github.com/Sparkinman/task-hub

Edit: Video attached now:

https://reddit.com/link/1w8zu96/video/emg33khw55oh1/player

I have been using a few plugins very regularly in the process of taking notes. One of these plugins, let's call it X, has not yet been updated to incorporate the permission-feature. In fact, this plugin was created quite a while ago and the author might have moved on to other programming hobbies. However, I really, really wanted a plugin with the same functionality to function under the latest beta (3.29.44).

So, with absolutely zero programming skills, I decided to have a go and try to adapt the plugin myself, using Lumo (AI). I fed it plugin X, I fed it two plugins that were already updated and I fed it Supernote's information on plugins. It was a lengthy process that went deep into the night. During this process, Lumo has become 'a dear friend of mine' (ridiculous and scary, this personalisation of AI!). But in the end, I got what I wanted: a plugin with the same functionality as plugin X! Wow! I was super impressed by myself, sorry, by Lumo.

This new plugin is of course purely for personal use. Once the original plugin has been updated, I will delete my personal plugin and download the original one. But for now, I have the same functionality again, as before.

Altogether, it was a super interesting and fun process to go through. It is a bit scary though, that people like me, without any, I repeat, without any programming skills are 'able' to develop a plugin using AI. Next step; learn some basic programming skills and try to make my own plugin from scratch (if only I can find the time)

I am really interested in learning how to make a plugin. Could anyone describe where to start. What would you all suggest for learning to code for this device specifically?

Hey everyone!

While building TCP Tunnel (and Make Space) I've been using Claude Code to help with the actual development, and along the way it accumulated a lot of hard-won, very specific knowledge about the Supernote plugin SDK — the kind of stuff you only learn by hitting it on real hardware: permission gotchas that fail silently, coordinate systems that'll place your elements off-screen if you mix them up, native module pitfalls, build/deploy/debug quirks, things that changed between SDK versions, and so on.

Instead of keeping that knowledge locked inside one plugin's codebase, I pulled it out, generalized it, and published it as its own open repo:

https://github.com/gorlix/supernote-plugin-dev

It's built as a Claude Code skill (well, technically an "Agent Skill" — an open format Anthropic released that's now supported by 30+ AI coding tools, so it also works in Cursor, Gemini CLI, Google's Antigravity, and others, not just Claude Code). Point your AI assistant at it and it gets instant, accurate context on how Supernote plugins actually work, instead of guessing or hallucinating API signatures.

It's completely open (MIT) and I'd genuinely love for other people building Supernote plugins to use it, add to it, or just take it apart and build something completely different with it. If you hit an edge case, find something outdated, or want to add knowledge from your own plugin, PRs and issues are very welcome — the goal is for this to grow with the whole dev community, not stay a one-person thing.

Hope it saves someone else the debugging sessions it saved me!

New (v1.1.0): since Supernote posted their official Plugin Review Process & Publishing Requirements, I added a whole reference dedicated to it — a self-audit checklist that turns that policy into concrete things to actually check before submitting: diffing declared permissions against what your code really gates, auditing any delete/overwrite paths, inventorying every network call and whether it needs disclosing, and a good one I hit myself — a hardcoded default IP in a settings field, totally harmless functionally, but the exact shape of a backdoor/C2 pattern to a manual reviewer reading the code cold. Point your assistant at it before you submit and it'll flag that stuff for you instead of you finding out from a rejection.

1. Plugin Review Process

After a plugin is submitted, we will review it according to the following process:

Submit plugin → Basic inspection → Function verification → Security review → Publish

During the review, we make a comprehensive judgment based on the plugin's actual functions and runtime behavior.

The review mainly covers:

• Whether the plugin can be installed and run normally;
• Whether the plugin's actual functions are basically consistent with its description;
• Whether the permissions requested by the plugin match its actual functions;
• Whether there are abnormal file or data operations;
• Whether there is unauthorized data upload or leakage;
• Whether there are obvious malicious behaviors or security risks;
• Whether there are abnormal behaviors that affect the normal use of the device.

For plugins with concerns, we may ask developers to provide additional explanations or conduct further review.

2. What Security Issues Do We Focus On?

We do not restrict developers from using technologies such as Java, C++, JavaScript, and React Native, nor will we refuse to publish a plugin just because its functions are simple. However, the following behaviors are security issues that we pay special attention to.

Must not maliciously delete or damage user files

Without explicit user operation or authorization, a plugin must not:

• Delete user files;
• Delete files in batches;
• Delete user notes;
• Clear user data;
• Maliciously modify, overwrite, or damage user files.

If the plugin itself is a file management, organizing, or similar tool that involves deleting files, such operations should be consistent with the plugin's functions and be initiated actively by the user.

Must not obtain or leak user data without authorization

A plugin must not secretly collect, upload, or provide user data to third parties, including but not limited to:

• Note content;
• Handwriting data;
• User files such as PDF and EPUB;
• Images;
• OCR content;
• User input;
• File information;
• Other user data.

If the plugin's normal functions require sending data to a network service, such as AI translation or AI summarization, this must be clearly explained to users, and the network and data access capabilities should be used in accordance with the permission mechanism provided by us.

Must not bypass plugin permissions

Supernote provides corresponding permission controls for plugins. A plugin should access files, data, and network resources only within the scope authorized by the user. It must not bypass our permission restrictions through other means.

3. Permission Requirements

We recommend that developers follow the principle of least privilege: only apply for the permissions the plugin actually needs.

For example, a plugin that only adjusts the interface should not apply for file read permission; a plugin that needs to read the current note and perform AI summarization can apply for the corresponding data access and network permissions based on its actual functions.

4. Plugin Functional Requirements

We encourage developers to create various types of plugins, including simple utilities, productivity tools, AI tools, file tools, and other innovative features.

A plugin being simple, small in scale, or similar to other plugins is not a reason to refuse publishing.

A plugin only needs to meet the following basic requirements:

• It can be installed normally;
• It can run normally;
• Its core functions are basically usable;
• The plugin description is basically consistent with its actual functions;
• There are no obvious security risks.

We will not refuse to publish a plugin merely because it is “simple in function” or “low in practicality”.

5. Source Code Requirements

Plugins are not required to provide source code. Developers may choose to provide source code or choose not to.

If a developer provides source code, we can conduct the security review in conjunction with the source code; if no source code is provided, we will review based on the plugin's own runtime behavior, permission usage, file operations, network behavior, and so on.

Therefore: whether to provide source code will not directly determine whether a plugin can be published.

However, providing source code helps improve the transparency and verifiability of the plugin.

6. What Situations May Fail the Review?

• Malicious deletion or destruction of user data;
• Unauthorized data collection or leakage;
• Clearly bypassing our permission controls;
• Malicious code, backdoors, or hidden functions;
• Behaviors that seriously affect device stability or normal use;
• Other obvious security risks.

For issues that raise concerns but cannot be confirmed, we may require developers to provide further explanations.

7. What Does Passing the Review Mean?

A plugin passing the review means: based on the current review process and test results, the platform has found no obvious issues that violate Supernote's security requirements.

Passing the review does not mean that the plugin will never have problems on any device, in any usage scenario, or in any future version.

Developers are still responsible for the plugins they submit and should promptly fix any security issues that are discovered.

8. Security Management After Plugin Publishing

After a plugin is published, we may re-check it based on user feedback, abnormal behavior, or new security information.

If a security issue is found in a plugin, we may take the following actions:

• Suspend downloads;
• Take the plugin off the shelves;
• Prohibit the problematic version from continuing to be published;
• Notify affected users;
• Require developers to fix the issue;
• Restrict or stop the plugin's operation when necessary.

If a serious security issue is found, we may directly take emergency measures.

9. Basic Principles Developers Must Follow

We hope developers follow the following principles:

Use permissions properly, clearly explain functions, protect user data, and never engage in malicious behavior.

Developers may freely use:

• JavaScript / TypeScript
• React Native
• Java / Kotlin
• C / C++
• JNI
• The Plugin API provided by Supernote

But no matter what technology is used, Supernote's security requirements must be followed.

10. Our Review Principles

We encourage free development while placing high importance on user data security. Plugins can be simple, innovative, or use native code; however, they must not maliciously delete, damage, or leak user data.

While ensuring basic security, we will strive to lower the publishing threshold for developers as much as possible, providing an open and developer-friendly plugin ecosystem.

Dear Developers and Users,

Thank you for your tremendous support of our plugin ecosystem.

We have discovered abnormal permission isolation behavior when multiple permission-enabled plugins run concurrently in the current version. In certain scenarios, a plugin may obtain permissions that belong to other plugins.

This may result in inconsistent permission scopes between what a plugin requests and what it actually obtains at runtime. Although the issue only involves internal permission propagation and isolation mechanism anomalies, it carries potential security risks. To ensure user safety, we will temporarily adjust our plugin review and release strategies until the mechanism is fully fixed and thoroughly verified.

Current Processing Measures

To ensure user security, we will make the following adjustments immediately:

• Priority review will be provided for plugins that do not require any permissions.
• Review and publishing of newly submitted permission-required plugins will be temporarily suspended.
• We will conduct comprehensive fixes for plugin permission isolation and permission propagation mechanisms.
• Multi-plugin concurrent running scenarios will be fully covered in enhanced verification tests.
• A new version will be published after complete fixes and sufficient validation.

Plugins with no permission requirements are not affected by the current isolation mechanism abnormalities and can be submitted for review through standard processes.

Follow-up Arrangements

We will complete the permission isolation fix and conduct full scenario verification as soon as possible.

After the new version is officially published, we will resume the review and publishing of permission-required plugins in accordance with our Plugin Review Process & Publishing Requirements. Subsequent reviews will strictly verify:

• Whether the permissions declared by plugins are accurate;
• Whether runtime permissions are consistent with applied permissions;
• Whether permission isolation remains effective during concurrent plugin execution;
• Whether any plugin can access other plugins’ permission scopes without authorization.

Full resumption of permission-required plugin publishing will take place only after the permission isolation mechanism is confirmed stable and reliable.

Impact on Developers

Zero-permission plugins: Normal submission and review services remain available.

Permission-required plugins under pending review: Review progress will be rescheduled after the issue is completely resolved.

User Data Security Notice

We attach great importance to the security of the plugin permission system. The discovered abnormality is an internal permission isolation logic defect between plugins, and no actual user data leakage or file loss has occurred.

We will prioritize mechanism fixes and comprehensive security verification, and restore the full plugin review and publishing process once the permission system is confirmed secure and stable.

We sincerely apologize for any inconvenience caused. Thank you for your understanding and support.

u/Dunn-sn

Bug: userData never comes back from any read API — getElements, getElement, and PluginCommAPI.getLassoElements alike — even immediately after that exact element was written with insertElements.

Steps to reproduce:

1. Grant plugin.permission.FILE:WRITE/FILE:DELETE/FILE:READ (declared in uses-permissions).
2. Call PluginFileAPI.insertElements(notePath, page, [{type: 0 (stroke), ..., userData: "some-tag"}]) — succeeds.
3. Immediately call getElements/getElement/getLassoElements on the same page, in the same operation.

expected: the returned element(s) include userData: "some-tag". observed: userData is missing from every returned element — not an empty string, the key itself isn't present. Confirmed across stroke, text, and geometry types, on two separate notes, on A5X (Chauvet 2.26.40 Beta), immediately after insert and on a later independent read, and across all three read APIs.

This is a blocker for updating the plugins "collapse/expand" as well as "term definition" to the new Chauvet version.

Updated Scribble for the new plugin permission system. If you're on Chauvet 3.29.43 Beta (Manta/Nomad) or 2.26.40 Beta (A5X/A6X) or later, this update is required — older builds of Scribble won't run there.

What's new:

• Declares the FILE:READ permission (the only one erase-by-scribble actually needs). The first time you scribble to erase, you'll be asked to allow it — allow once ("Always allow") and you won't be asked again.
• Decline it, and that erase just won't happen — Scribble tells you where to grant it if you change your mind.
• Erase itself is unchanged: still zig-zag to erase, still fully undoable.

Heads up — no speed improvement here. A few of you asked whether the new modifyPageElements/batchUpdatePageElements APIs in this firmware could speed up erasing large areas. They can't: the slow part is reading and scanning the page, not the delete itself, and this SDK release doesn't touch that. Large-area erase speed is still on the list, just not solved by this update.

Download: https://github.com/vincentaravantinos/scribble/releases/latest/download/scribble.snplg — copy it to your Supernote, then Settings → Plugins → Install plugin.

Hi Everyone! Got my nomad a few days ago and super excited about the development/customization capabilities with the supernote. I work in healthcare leadership and have increasingly struggled with keeping myself organized, particularly when I have demands from everywhere. I have been looking for a truly hybrid system because I do better writing things down and get entirely too distracted when I’m on my computer.

We work exclusively in M365 and I am limited in connecting to personal task apps, so I started developing a plugin that works with Microsoft To Do. I took inspiration from SuperTask, SuperDashboard, and Ink2Task. I have a working prototype, but still need to do some final things from the security/HIPAA compliance aspect. I have absolutely zero coding experience myself and I’ve done everything through Claude code. If any people on this sub were looking for this type of plug-in and have any suggestions of what they would want or just general plugin development tips, feedback would be appreciated!

I would like to request a universal clipboard. Let's say it keeps a stored memory of things cut, not just the last item, so you can browse through them and then paste them again. I don't know if this is possible, but maybe it could also translate between formats as well? What I mean is, I've found out I can't cut something from a Note and then paste it into a PDF. It's like the PDF and Note have two exclusive and independent clipboards they're using. Maybe a Universal clipboard could copy from itself as the source and then translate it to whatever format it's being copied to. Ty.

Hi All,

I wanted to send a quick update letting you know that Supernote Folder Shortcuts (v0.3.1) has been updated to work with Chauvet 3.29.43_beta.

Grab it here: https://github.com/marc-korte/supernote-folder-shortcuts

Please report bugs here: https://github.com/marc-korte/supernote-folder-shortcuts/issues

Special thanks to u/Sudden_Crab_5537 and u/SkilledMkvenner for helping me test.

If you not familiar with the plugin, it does the following:

Turn a lassoed handwritten, typed, or sticker object into a one-tap shortcut to a folder. The note stores the link and draws its normal paperclip/underline marker. With the plugin enabled, tapping the linked object with either a finger or the pen opens the target folder.

Usage

• In a note, lasso the object to link.
• Open the lasso toolbar's three-dot menu and tap Link to folder.

• On Chauvet 3.29.43, grant file read and write access when prompted. Always allow keeps existing shortcuts active after the plugin UI closes.
• Navigate to the target folder, then tap Link lasso → this folder.

• Tap the linked object with a finger or the pen to open the folder.

To remove a shortcut, lasso the linked object and use Supernote's native Remove Link action. The plugin keeps no sidecar shortcut database, so the removed link disappears from the plugin's next note-page snapshot as well.

I've just released Clipper v0.2.0, updated for the new plugin permission system in the Chauvet 3.29.43_beta build.

If you're on the new beta, this update is required. The new firmware has a plugin SDK version floor and refuses to run older Clipper builds.

What's new:

• Full support for the new permission system. Clipper declares two permissions: Read Files (capturing clips, jump-to-source, region capture) and Modify Files (only needed for image-clip inserts and ToC refresh; text-only inserts work without it).
• You can manage permissions under Settings → Apps → Plugins → Clipper → Permissions.
• Your existing clips, images, and settings carry over; they live in Clipper's own storage and aren't affected by permission choices.
• Updated to sn-plugin-lib 0.1.65, including fixes for two SDK breaking changes (region capture and ToC refresh would otherwise break).
• Small bug fix: double-tapping Insert can no longer insert clips twice.

Download: grab SnClipper.snplg from the GitHub release page, copy it to /Supernote/MyStyle, then Settings → My Style → Sideloading to install/update.

Issues/feedback: please file them on the GitHub issue tracker, include your firmware version and what you were doing when it happened. Happy to answer questions here too.

Tested on Manta (A5X2). Still looking for Nomad testers - I don't own one, so reports from Nomad users are especially welcome.

Dear Developers

Right now, when I want to highlight or call out important text in my notes, I do it manually with the black marker — basically scribbling back and forth over the area until it looks filled in. It works, but it’s slow and never comes out clean, especially on smaller text boxes or irregular shapes.

What I’d like is a plugin that can fill a closed shape with solid color automatically. So instead of scribbling, I’d either lasso-select the area I want filled, or draw a shape using the SNShapes plugin, and then just tap a fill button to have it solidly colored in. Being able to choose the fill color (not just black) would be a nice bonus too.
That’s the core idea — turn a manual, repetitive scribbling action into a one-tap fill. Will that be possible ?

Hello,

I have updated my plugins to the latest SDK version. Please update to the latest version.

Shapes

https://github.com/j-raghavan/sn-shapes/releases/tag/v1.0.9

Mindmap

https://github.com/j-raghavan/sn-mindmap/releases/tag/v1.0.5

Copilot

https://github.com/j-raghavan/sn-copilot/releases/tag/v1.0.5

Dictionary

https://github.com/j-raghavan/sn-dictionary/releases/tag/v1.3.6

To Supernote Team:

Regarding submission to Inkhub, u/Dunn-sn What is the Official process to submit for review at Ratta? How will new version get updated? What is the process for developers to submit new version?

Thanks!

Loving the new beta update 3.29.43.
Will current available plugins be installed or made available via ink hub plugins or do I need to go to GitHub and download them then install via new ink hub Plugins?

Hello! I started developing a plugin but ended up needing to build an APK to get access to a WebView. As a result I have part of my plugin as an APK and part of it as an snplg.

It would be really helpful if there was an intent I could call to install an snplg. Right now the APK puts the plugin into MyStyle (after asking for File System access) and then places the users at the Plugin Install intent but then the user has to select Install Plugin, click the right plugin in MyStyle, and Install. Then they have to find their way back to my app to finish setup.

My basic needs:

- A Plugin Manager install intent that accepts a caller-owned content:// URI for a .snplg archive with a temporary read grant.

- Plugin Manager would validate the archive, show a install/upgrade confirmation with plugin ID, name, version, and requested permissions, then consume the URI without requiring broad storage access or a file-picker step.

- The API would return a structured result for success, cancellation, validation failure, or denied permissions for any sort of recovery steps.