Uploading Branding Materials for NeuroAccess

Uploading Branding Materials for NeuroAccess

1. Introduction

Branding in NeuroAccess lets you customize the look of your NeuroAccess app for end users. By publishing colors and images to the broker’s PubSub service, any client connected can pick up your brand automatically.

2. Prerequisites

• Access to the PubSub service on your broker
• Hosted ResourceDictionary XAML and image files (see steps below)

3. Architecture Overview

3.1 Hosting branding description in the PubSub service

NeuroAccess, when connecting to a broker, looks for a node named NeuroAccessBranding and expects it to have an item with ID Branding, containing a <BrandingDescriptor> payload. The app downloads and caches this data for a set period.

3.2 The NeuroAccessBranding node

• Node name: NeuroAccessBranding
• Item ID: Branding
• Payload: <BrandingDescriptor> element

4. Branding Descriptor Schema

The descriptor lives in the Branding PubSub item and must match the XML schema. See the full schema here: NeuroAccessBrandingV1.xsd

Key elements:

• <Version major="2" minor="5" patch="1"/> — last supported NeuroAccess release version
• <ColorsUri>…</ColorsUri> — HTTP or XMPP URI to a MAUI ResourceDictionary
• <Images> with one or more <ImageRef id="…" uri="…" contentType="…"/>

4.1 Versioning

Although NeuroAccess currently ignores the version at the time of writing, it is critical for future compatibility. By incrementing semantic version attributes (major, minor, patch), you can publish new branding descriptors that only newer versions of the app will apply. This allows you to roll out multiple themes in parallel—each keyed by version—without changing the schema or node name.

Note: NeuroAccess currently always looks for a Branding item. So at the time of writing, publishing multiple versioned themes is not supported. Also the versioning is only planned to allow for the app to resolve conflict between multiple items. In the case the app is version 2.6.0 and the provided theme is 2.5.1 it will still use that.

5. Step-by-Step Guide

5.1 Prepare your color palette

1. Create MyColors.xaml:

<ResourceDictionary
  xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
  xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml">

<Color x:Key="ExamplePrimaryColor">#123456</Color>
<Color x:Key="ExampleSecondaryColor">#ABCDEF</Color>
</ResourceDictionary>

2. Host it so it’s reachable at one of:

• HTTP (for example, https://neuron.example.com/MyColors.xaml)
• XMPP PubSub: publish it as an item with ID Colors on NeuroAccessBranding, then URI: xmpp:NeuroAccessBranding@pubsub.example.neuron.com/Colors

Tip: Using XMPP URIs keeps everything within the broker—no external server required.

5.2 Prepare image assets

1. Upload images so they are accessible using HTTP: https://neuron.example.com/<filename>
2. Recommended IDs (add more if needed):

• banner_large_light
• banner_large_dark
• banner_small_light
• banner_small_dark

3. Record each asset’s ID, URI (for example, https://neuron.example.com/banner-large-light.png), and contentType (for example, image/png).

Tip: You can store image files in the broker’s Root folder so they’re publicly accessible at a simple HTTP URL (for example, https://neuron.example.com/BrandingMaterial/banner.png).

5.3 Publish theme descriptor

Create the Branding item payload:

<BrandingDescriptor xmlns='urn:neuroaccess:branding:1.0'>
  <Version major='1' minor='0' patch='0'/>
  <ColorsUri>
    xmpp:NeuroAccessBranding@pubsub.example.neuron.com/Colors
  </ColorsUri>
  <Images>
    <ImageRef
      id='banner_large_light'
      uri='https://neuron.example.com/banner-large-light.png'
      contentType='image/png'/>
    <ImageRef
      id='banner_large_dark'
      uri='https://neuron.example.com/banner-large-dark.png'
      contentType='image/png'/>
  </Images>
</BrandingDescriptor>

And publish it on the pubsub node NeuroAccessBranding with the item id Branding

5.4 Verify in NeuroAccess

1. Connect using NeuroAccess to your broker.
2. The app fetches NeuroAccessBranding→Branding.
3. It applies your colors and images in the UI.

6. Troubleshooting

• No branding?

• Verify node: NeuroAccessBranding
• Verify item IDs: Colors, Branding
• Clear cache in NeuroAccess settings and restart
• Images not showing?
• Open URIs in a browser
• Check contentType values

7. Conclusion

A ResourceDictionary and image files let you brand your NeuroAccess app entirely via PubSub—no app update needed. Version descriptors for seamless theme updates.

8. References

• NeuroAccess Branding schema: NeuroAccessBrandingV1.xsd

• Colors XAML example: Colors.xaml

• .NET MAUI ResourceDictionary docs: MS Docs

#access, #neuroaccess, #neuro-access, #branding, #theme

Quick-Admin-Login

It is now possible to associate a legal ID (or a Neuro-Access ID) with an administrative account on the Neuron®, from the build 2025-01-21. The login page now shows an animated QR code that you can can using the Neuro-Access app.

To associate a Neuro-Access ID (or legal ID) to a user account, edit the corresponding user. You will see three fields that have to be provided: The current Legal ID and the corresponding personal number and country code. You can get these from quicklog.in if not known.

Once the information has been provided, you can login to the administrative console of the Neuron® using the corresponding legal ID.

Updating ID

As legal identities are limited in time, there will come a point when an ID needs to be updated. This will obsolete the old ID, which will be replaced by a new one. As long as this process is followed (i.e. old ID is obsoleted) and the new ID contains the same personal number and country code you can also use the new ID to login to the same user account. The legal identity reference will be correspondingly updated, and an event will be logged, for reference.

Event Log

All administrative logins are logged to the event log, so too the logins using Neuro-Access digital identities. The message text and corresponding properties may be different. Any problems such as duplicate legal identities associeted with multiple accounts, etc., will also be displayed in the event log.

#new, #features, #neuron, #admin, #neuro-access, #quicklogin

Content-Only Service Template

A new open repository has been published that simplifies the creation of new services that only publish content-files on the TAG Neuron®. The repository also contains instructions on how to implement such a service and the different steps that need to be completed in order to create an installable package for the service, to distribute it in a Neuron® network. It also shows how to implement a service that lets users login using Neuro-Access, or the administrative interface.

For more information, see the TemplateContentOnlyPackage on GitHub.

#new, #repository, #neuron, #neuro-access

Development Neurons and Neuro-Access integration

If you are developing a local project on a locally hosted development Neuron®, and you want to integrate Neuro-Access to let users to login to show protected pages, your development Neuron® must be configured to permit this. This is done by adding the XMPP addresses (JIDs) of the apps involved during development to the Roster of the development Neuron®. On published Neurons, this is not necessary, as they are federated and use their domain names to interconnect with other Neurons (such as the Neurons serving your Neuro-Access connections). But a developer Neuron® cannot do this, as it most probably lacks both a domain name and a public IP address. Communication in this case, is done using the XMPP Addresses (JIDs) of the Neurons, as clients to their parent Neurons (which are federated). For communication to pass in this case, and not be rejected as invalid, the sender has to reside in the Neurons Roster (accessible from the Admin page, in the Communication section).

#neuron, #neuro-access, #development

Recovering Neuro-Access accounts from script

Before reading this post I would recommend having a look at the following post: obinfo URI scheme

---

When someone has lost access to their Neuro-Access account, you can provide the app with the required information for a recovery trough obinfo URIs. The following code will show you how to go about creating an obinfo URI for account recovery. Note that is is not the same as a Transfer between devices as this will invalidate any identities connected to the account

---

Get the account information

It is required to know the account name of the user

UserName:= "FooBar";
Account:=Waher.Service.IoTBroker.XmppServerModule.GetAccount(UserName);

Expiry date

Set for how long the account information will be available

Expires:= Today.AddDays(7)

Create the account info

GW:=Waher.IoTGateway.Gateway;
Data:=<Account xmlns="http://waher.se/schema/Onboarding/v1.xsd"
				userName=Account.UserName
				password=Account.Password
				domain=GW.Domain />;
Data:=Utf8Encode(str(Data));
Key:=RandomBytes(16);
IV:=RandomBytes(16);
Data:=Aes256Encrypt(Data,Key,IV);
Req:=<Info xmlns="http://waher.se/schema/Onboarding/v1.xsd" 
			base64=Base64Encode(Data)
			once=true 
			expires=Expires.ToUniversalTime() />;
OnboardingDomainName:=Waher.Service.IoTBroker.Legal.LegalComponent.GetOnboardingNeuronDomainName();
Info:=GW.XmppClient.IqSet("onboarding."+OnboardingDomainName,str(Req),10000);

Create the URI

Code:=select /default:Code/@code from Xml(Info.InnerXml);
URL:="obinfo:"+OnboardingDomainName+":"+Code+":"+Base64Encode(Key)+":"+Base64Encode(IV);

#neuro-access