So we started the shift to Flatcar Linux, a container focussed distribution that picked up what CoreOS had been doing before RedHat decided to kill it off.

But there was a problem. We were using the Google Ops Agent to get metrics from inside our Ubuntu VMs, and Flatcar isn't one of the supported distros. I raised an issue with the Flatcar team, but it quickly became clear that Ops Agent wasn't a good fit for their approach.

Meanwhile we noticed that our monitoring bill was HUGE. It turns out that the default for Ops Agent is to monitor every process (in detail), which can get expensive when you're running hundred to thousands of containers per node :0

We shut down Ops Agent, and briefly replaced it with a 'ghetto' monitoring script. But this was the push we needed to get a custom metrics solution in place.

Of course there's an API for Stackdriver, and like most things Google Cloud there's good support for Python and Golang SDKs. A quick search brought me to Arpana Mehta's Getting started with Google Cloud Monitoring APIs, which had the boilerplate code I needed to customise. After adding in CPU Load Average, I had our most crucial metric (and I returned to my script a few days later to add in root volume utilisation).

With a working script in the staging environment I then packaged it up (along with the google-cloud-monitoring package) into a Docker container that could be deployed across our Swarm nodes. After less than a day of 'ghetto' monitoring we were back to seeing everything we needed in our dashboard, with much lower ingestion and storage charges, as we're only sending the metrics we need rather than everything about everything.

The script, Dockerfile etc. are now open source - at_swarm_load.

We've also found that the same approach can be used to monitor our CI/CD VMs on AWS. It's a little more fiddly, due to the need for service account files, but means we can use a single dashboard to keep an eye on things.

dess is an acronym which stands for:

d. Distributed e. Edge s. Secondary s. Server

Pre-requisites

• Registered atSign(s) to setup (get free/paid from here )

• An AWS account (sign up/in here )

• A Fully Qualified Domain Name (FQDN)

1. Registering your atSign

This topic is already well documented! Please follow the guidance of The atPlatform FAQs and register via the registrar site.

2. Sign-up for AWS account

If you are new to AWS, signing up for an account is free! The cost of running dess is about $10/month. You can create your account here and as of June 6th, 2021 there is a “free tier” available which was used during the original making of this guide which can be found on atsign.dev.

Follow the instructions on screen.

Once you are done with registration, you will be able to login to your aws console.

Make sure that you select the correct region in the top right corner.

Select the region that is geographically closest to your location for best performance.

You are now setup on AWS and ready to prepare dess.

3. Register your own fully qualified domain name (FQDN)

This step can be performed at a variety of sites, all with different pricing models. You can use sites like Go Daddy, Namecheap, and many others. However, since we have AWS account, we can use it to register our domain through the Route 53 service.

In your AWS console navigate to services in top left corner and select Route 53.

a) Register domain name with AWS.

In your AWS console search for Route 53.

You can start looking for your domain directly from here:

Based on the domain name you search, AWS will give you similar options, and their pricing. As I am looking for the best deal, the .link domain seems like a good option at a cost of 5$ / year.

In my case 4atsign.link is free and I will register it by clicking “Add to cart” and continue.

Fill out DNS registration form:

Continue review details and order. At this point if all is fine you should see your domain request pending:

This can take some time so why don’t we move on to next step!

4. Preparing AWS instance

Now since I am new to AWS, the easiest way to get started is by using the LightSail service from service catalog. This will enable you to deploy small system which is more then capable of handling dess at pre-set price.

Welcome to LightSail:

First step is to create new instance. Fortunately, we have big orange button that can do just that!

There are several options we are presented at this moment. Since I am living in Europe I select “Frankfurt, Zone A (eu-central-1a)” as my instance location. Instance region will dictate how well will your instance response based on your geographical location. People located in India should selects APAC region where as people in US should select North America region. You can leave availability zone set as default.

Next up will be selection of operating system we want to deploy. We know that dess works well with Ubuntu 20.04 LTS so let's select just that.

You are presented with a couple more options, but unless you know what you are doing leave these as is.

Now let’s select an instance plan. dess is relatively light weight so for testing purposes I will select the first instance plan for $3.5/Month. This will provide us with 512 MB of RAM, 1vCPU, 20GB of storage and 1TB of data transfer. This is more than enough to run our dess.

Lastly we have to name our instance. This is the name you will be presented with in your dashboard.

Last but not least is to press “Create instance”:

After a couple of seconds you should be re-routed to your dashboard and see your instance up and running:

5. Preparing your instance for network access

a) Assignment of Static IP

Next up, is to provide our instance with a static IP and linking our domain to it.

When you click on your instance name, it will take you to the management console, which should look like this:

This is where you control hardware, connectivity and if needed can delete your instance.

Lets configure a static IP address for your new instance. Navigate to Networking and click on Create static IP:

Our region and instance is selected, so the only thing left is to name our static IP. I selected the name atsign-static, but it can be any name you like.

Let's hit create:

And voila, we now have a static IP address on the internet and it will not change. Now we can link our domain name with it.

When you click on your instance name and navigate to Networking, the static IP is now assigned.

b) Assignment of Domain name to your static IP

We can now move on to linking our static IP address to our domain. This is done via the AWS console which can be accessed in the top right of Lightsail.

Verify your email used for registering domain:

By now you should receive a verification email that will confirm registration of your domain. Click this link before moving on.

Linking domain with your static address:

Let's navigate to “Route 53” from Services menu.

From your dashboard click on “Domain” which will take you to the “Registered Domains” tab.

Here you can click on your registered domain which will take you to overview page with domain status and contacts.

Click on “Manage DNS”:

And click on your domain name.

This will show you your DNS records for your domain. We now need to link A type record to your domain linking it to IP address of your instance.

This is done simply by typing your static IP address from previous step into field “Value” and clicking Create record:

If everything goes well you should see following in your domain dashboard:

To test if you are successful open command line and ping your domain. You should see your instance static IP address. It will not respond which is normal due to IPv4 firewall. It is actually good thing!

At this point we have created a DNS record we will use to link our dess. We created an instance name which will be running our dess and we have opened a port range which is exposed to the internet and we can communicate with the atSign root server and our apps.

c) Setting up Firewall

Next up, we need to make sure we have ports open for our dess to communicate with the root server and our apps. In Section networking go to section “IPv4 Firewall” and click “+ Add rule”. Our rule will be “Custom” on TCP protocol with Port range in a number higher than 1024. In my case, I have selected port range 8000-8010. This will enable me to run up to 10 atSigns in parallel.

Click create and verify that your new rule is in list:

6. Instance setup and dess deployment

Open your LightSail console

By now you should see your instance in “Running state”

Open it and on the tab Connect click on “Connect using SSH”

You should be presented by a new window with command line:

Before we do anything else, we should update the system:

sudo apt update && sudo apt upgrade

This might take some time, but it will make sure we have latest repository information and the system is up-to-date.

Next make sure curl is installed, we will use curl to pull the dess installation file:

sudo apt install curl

Finally, run the dess installer:

curl -fsSL https://getdess.atsign.com | sudo bash

Once the installer is finished you should be prompted like so:

Dess installed, please move on to the sudo dess-create command.

7. Registration of atSign in your private dess

At this step, you should already have your atSign registered at http://atsign.com. If not go do it!

I have registered my own free atSign (@ 44likelycanary) which I will link to my dess.

In your instance console, navigate to dess folder.

We now need to create the service that will host our atSign by executing the dess-create command:

$ sudo dess-create @44likelycanary 4atsign.link 8000 <email address> likelycanary

To make it more understandable:

I will be registering my atSign @44likelycanary.

I will be using my domain 4atsign.link which I have registered through AWS.

I am using port 8000 which I have opened in my instance firewall.

My registration email address is <email address> (this email is used to sign the SSL certificates).

The last likelycanary is the name that docker will use to track the service.

If everything is successful you should see output like this:

At this moment your atSign is registered on your dess.

8. Activation of atSign

Next up we need to activate it

Login to your dashboard here

Open “my atSigns”

Open “managed” of atSign you are registering”

Navigate to Advance settings:

If you have already activated your atSign you will be prompted to erase all your data first

Once done you are able to link your atSign with your private dess. Use your domain and port number with which you have created service on your cloud instance and press Activate.

You should see that your atSign is being activated in your dashboard:

This can take several minutes so go get a cup of coffee, some tea maybe, stretch your body and pray you haven’t made any mistakes!

Once the activation process completes you are welcomed by green Activated.

You can now open atBuzz or atWavi and register your atSign via QR code and generate your keys!

CONGRATULATIONS YOU'RE FINISHED!

The AtKey object is stored on an atSign’s personal secondary server (a separate article written on secondary servers), so dealing with databases is not a worry on the atPlatform. There are a few distinct attributes that exist within an AtKey.

String? Key;

The key is the title or name of the AtKey object itself, may this be a recipe name (like mom’s secret recipe from at_cookbook), or maybe even the name of a weather update (like, cloudy or sunny).

String? sharedWith;

The sharedWith attribute is as easy to understand as it is to read! This is simply the atSign in which we wish to share this AtKey object with, or who the AtKey object has already been shared with!

String? sharedBy;

Similar to sharedWith, sharedBy is just who the creator or original sender of the AtKey object is.

String? Namespace;

The namespace is the name of the app where the AtKey object was created. This is why passing the regular expression to retrieve AtKey objects from specific applications is a possibility.

Metadata? Metadata;

Metadata, which is commonly known as the data about the data, will be described in its own video series as there is much to it!

Taking a look at one of the atPlatform’s demo application, we can see the AtKey object in action. The at_cookbook app allows a testable or production level atSign to create a recipe with a name, description, list of ingredients, and a picture. After doing this, the atSign is capable of sharing this entire recipe with another testable atSign. A dishWidget class is created which encapsulates an individual recipe with each instance. Its parameters are defined below:

class DishWidget extends StatelessWiatdget {
 final String title;
 final String ingredients;
 final String description;
 final String imageURL;
 final String prevScreen;

 DishWidget({
   @required this.title,
   @required this.ingredients,
   @required this.description,
   @required this.imageURL,
   @required this.prevScreen,
});
...

After we pull dishWidgets that exist in a secondary server, we display them on the home screen, where the list of recipes are located.

Now that you have the recipe itself, you’re able to pass this through the notify verb. When an atSign wishes to share a recipe, the _share function will be called. This function is structured as so:

_share(BuildContext context, String sharedWith) async {
 if (sharedWith != null) {
   AtKey lookup = AtKey()
     ..key = widget.dishWidget.title
     ..sharedWith = atSign;

   String value = await _serverDemoService.get(lookup);

   var metadata = Metadata()..ttr = -1;
   AtKey atKey = AtKey()
     ..key = widget.dishWidget.title
     ..metadata = metadata
     ..sharedBy = atSign
     ..sharedWith = _otherAtSign;

   var operation = OperationEnum.update;
   await _serverDemoService.notify(atKey, value, operation);
   Navigator.pop(context);
 }
}

Here, we’re initializing a variable called lookup as an AtKey object (lookup will be our recipe). You’ll notice that we’re defining a couple of the attributes of the AtKey object (mainly the name of the recipe and what atSign is this recipe being shared with).

We would like to “get” the values of our recipe, so we use the get verb from the serverDemoService file of the application. ttr (Time To Refresh), a metadata attribute, is called with a value of -1, which means that we’re confident that the values of our recipe won’t change. Once the recipe has been cached on the secondary server that has received the recipe, it will not need to worry about updating its values at any point.

After passing all of the necessary values such as the metadata, the appropriate atSigns, and the type of notification we’d like to send, we simply pass the values through the notify verb!

** Watch our YouTube video that covers this article! **

How to implement at_onboarding_flutter:

Are you tired of setting up FireBase tables, handling usernames and passwords, and writing line after line of code setting up authentication methods and features?

Atsign has designed a platform (titled the atPlatform) which houses many packages that make the life of a developer easier! Let’s take a deep dive into one of these that greatly assists in authentication!

What you’re looking for is called at_onboarding_flutter! You can find it here, on pub.dev. You can quickly add it to your dependencies within your pubspec.yaml file like this (note: be sure that you check pub.dev for the most recent version!):

dependencies:
  at_onboarding_flutter: ^2.1.2

After successfully running the ‘pub get’ command which is when Flutter saves the concrete package version in your project, you can import its package within one of your files. This should look something like this:

import 'package:at_onboarding_flutter/at_onboarding_flutter.dart';

Congrats! After doing this, you’re already halfway to have an atSign authenticate into your application! You’ll need to pass in a few parameters such as; your build context, the current atClientPreference (covered in another article), your application’s domain (there are currently two that exist, one for production level which is ‘root.atsign.org’ and one for testing purposes - ‘vip.ve.atsign.zone’). You can also pass the color of your app as there is included U.I. with at_onboarding_flutter! You can then onboard by passing in the current atClientpreference and atSign you wish to authenticate to the current client instance. You can declare your own personalised successful or error log message, and be sure to state which screen the atSign will be navigated to upon successfully onboarding. Below, you will find what this may look like in code:

Onboarding(
context: context,
atClientPreference: atClientPreference,
domain: 'root.atsign.org' or 'vip.ve.aatsign.zone',
appColor: Color.fromARGB(255, 240, 94, 62),
appAPIKey: 'your-api-key-here',
onboard: (value, atsign) {
ClientSdkService.getInstance().atsign = atsign;
ClientSdkService.getInstance().atClientServiceMap = value;
ClientSdkService.getInstance().atClientServiceInstance = value[atsign];
_logger.finer('Successfully onboarded $atsign');
},
onError: (error) {
_logger.severe('Onboarding throws $error error');
},
nextScreen: HomeScreen(),
);

Just a few notes for the above code. I am calling some functions that exist in a file called ClientSdkService.dart. This file contains many useful functions that are pre-coded by the atPlatform core developers. To include this file in your own project (you’ll be able to explore than many other useful functions!), feel free to navigate to the atFoundation at_demos repository, which is open-source, on Github! The ClientSdkService file can be found in any of these demo applications under the same file path (or roughly the same) -> /complete_version/lib/service/.

Making reference to the demo applications, be sure to check out how the demo apps utilize at_onboarding_flutter!

If you wish to learn more about at_onboarding_flutter or maybe the atPlatform in its entirety, check it out on pub.dev and explore on atsign.dev and atsign.com!

Be sure to check our pub.dev to see the most up-to-date version at_events_flutter!

The first step, is the initialization of the event service. For demonstration purposes, in this article, we’ll be examining snippets from the example app in the at_events_flutter Github directory.

The most paramount function in the at_event_flutter library is CreateEvent(), which builds an instance of a CreateEvent that can be customized and shared across different atSigns as shown below:

CreateEvent() is a separate screen in the application that guides an individual through a list of fields they can populate to provide information about their event. If you look into the CreateEvent class, you’ll see that these fields are stored in an object called “eventData”, which is an instance of an EventNotificationModel. It’s full list of attributes is below (the ones with comments are used in the CreateEvent class):

“eventData” is a crucial data structure that’s used not just in creating an event but updating and deleting events as well. The init_events_service.dart file illustrates a variety of functions that can be used to perform useful actions on these objects.

One important feature of the example app is its EventList class, which doesn’t come directly with the at_events_flutter dependency:

This seemingly harmless class is actually doing quite a bit of work behind the scenes! EventList listens to an event stream that comes from an EventService object (a class within the at_event_flutter dependency) and displays them in a ListView format. Clicking on one of these events, you’ll be navigated to a popup of a CreateEvent instance with its “isUpdate” parameter set to true. This allows you to edit and save any event of your choice!

So, what events will you create with at_events_flutter?

Xavier Chanthavong is studying at Ontario Tech University for a Bachelor of Science in Computer Science. He is an avid learner and seeks to share his findings with the world. When he isn’t writing code or coming up with new ideas, you can find him playing guitar, or video games with his friends. We caught up with him to hear more on his experience using Dart/Flutter IDEs. Be sure to check out his LinkedIn and Github!

Tyler Trott, who is also studying at Ontario Tech University is enrolled in the Bachelor of Science in Computer Science with a specialization in Data Science. Tyler was actually part of the first group of interns ever at Atsign and has found himself as a Developer Advocate paving the way for the new wave of interns and developers! If he doesn’t have his nose buried in his computer, you’ll more than likely find him on the tennis court or the ski slopes! Maybe one day, he’ll figure out how to do both at the same time. Be sure to check out his LinkedIn and Github!

I asked the two whether there was an IDE which focuses on development in Dart/Flutter, here are their thoughts:

First, Tyler explains that there is no specific Integrated Development Environment (or IDE) for Dart/Flutter but there are a few general IDE’s that allow for development with the two and the ones that come to mind very quickly are Android Studio, IntelliJ and Visual Studio Code. Xavier adds that those are the ones recommended by Flutter. Hence, the three would be the best options. Tyler adds that Visual Studio Code is his favourite IDE for the long term due to the almost seemingly endless list of programming languages that are supported on the platform, but Xavier mentions that Android Studio is easier to use when you are new to Dart/Flutter due to its more app development based purpose.

We then went on to discuss the basis of Flutter/Dart, just a quick understanding of the two: Xavier goes first to share that Flutter is a very declarative language and is supposed to be treated as reading a function of states, but in some cases what is really powerful is being able to define abstract classes or implement things such object orientated programming into your data model. Because you can have some flexible stuff going on behind the scenes which you don’t have the option to do with something such as React-Native as easily.

Furthermore, he explains that Dart/Flutter is somewhere between C language and Javascript/Typescript which gives a lot of flexibility on how you can treat the language. In addition, the learning curve is low, hence if you know any of these languages, it would be easy to catch up with Dart/Flutter. Tyler adds to the discussion that he comes from a C++ background, and it was easy to get into Dart because of this. Dart can be a ‘boring’ language, meaning it doesn’t have incredibly innovative workings and can tend to feel very complex such as a typical C language, but can be quite hard to get a hang of if you are coming from the aforementioned languages.

Now digging deeper into the Flutter recommended IDE’s:

Android Studio

To begin with Android Studio, it is a wonderful environment to create projects for Android devices whilst simultaneously allowing you to set up an Android Virtual Device (or AVD) to emulate these projects developed for testing purposes. If you are looking for an easy IDE to get started on, this is the one recommended by the @ Company. You’ll find that most of the code, documentation, and tutorials are created with Android Studio at Atsign.

Visual Studio

Visual Studio Code, often referred to as VS Code, when compared to Android Studio is the most customizable. Most of the Atsign developers also use Visual Studio Code. VS Code has many community-driven extensions that allow for ease of life such as Bracket Colorizer, Better Comments and Error LEns, just to name a few.

IntelliJ

IntelliJ is another commonly used IDE, which has a similar feel to Android Studio (as Android Studio is powered by IntelliJ!).

I asked Xavier and Tyler for some of the common Keyboard Shortcuts that can be utilized: In this section, we will focus on the shortcuts used with VS Code, but may also be applicable when using other IDE’s. Time is precious and there are shortcuts that help a lot when coding. You can find the list of default keyboard shortcuts and search for shortcuts by using CTRL+K+S. Below, I’ve listed some of these shortcuts.

Code Assist or Code Completion (Ctrl + Space) While coding, this is one of the important tools, especially for beginners or if you get stuck somewhere and would like to check for options, you can use Ctrl+Space to get a list of curated code completion options.

Quick Fix or the Magic Wand (Ctrl + . => Quick Fix)

For faster development in Flutter, you can use the quick fix tool which is Ctrl+.. This helps in fixing the code with some additional requirements without messing with your code or your widget structure and gives you less headache of manually correcting everything.

Extract Widget (Ctrl + . => Extract Widget)

This can come in handy a lot if you want to split your widgets into smaller widgets. Just click on any widget and then click Ctrl+. and click Extract Widget option and give a name for the new widget and click Enter and that is it.

Stateless Widget to Stateful Widget (Ctrl + . => Convert to Stateful Widget)

Now let us say, you wanted a Stateful widget, but have already set up a Stateless Widget. Simply select the Stateless Widget you wish to convert and click Ctrl + . and then select the option Convert to Stateful Widget and Vs Code will automatically convert this widget for you. Some Debugging Shortcuts: · F5 => Start Debugging · CTRL + F5 => Start Without Debugging · Shift + F5 (macOS: Cmd + Shift + F5) => Restart Debugging or Hot Reload

In conclusion, IDEs can be a useful tool that can save developers a lot of time and enable them to develop applications swiftly and efficiently. The aforementioned tips and tricks by Tyler and Xavier can guide and give a clear introduction to IDEs.

Be sure to check our pub.dev to see the most up-to-date version at_contacts_flutter!

In order to implement the at_contacts_flutter widget, you must first, of course, create an AtClientService instance and authenticate an atSign. If you look through the example application dedicated to the at_contacts_flutter widget, you will see on load that it asks you to either authenticate an atSign or use one that is already authenticated on your device.

After you have successfully onboarded an atSign, you will be taken to the page where you may choose to show your contacts or show your blocked contacts. On load of this page, the following code will run, creating an AtClientService instance. The contacts service needs to be initialized with the atClient from the AtClientService, current authenticated atSign, and the root domain.

After successfully initializing the contact service, you will now be capable of getting the list of contacts that exist for the authenticated atSign. This is as easy as simply passing the contacts into a variable.

This fetchContacts() function exists in the _contactService file, which can be found within the at_contact’s ‘services’ folder. If you want to do more than just get the list of contacts, you have the capability of adding more contacts to this list, in addition to removing or blocking any. In order to retrieve the list of blocked contacts, it is similar to retrieving the regular list of contacts. The code from the example app demonstrates this well.

To block a contact, it is as easy as calling the blockUnblock method. If a contact is blocked, it will unblock the contact. If the contact is not blocked, it will block it for you.

After you block a contact, you may wish to have that contact removed from the list. All you have to do is simply implement the code below:

Along with the previously stated functionalities, the at_contacts_flutter package also provides the UI so there’s no need to set up a separate page to house these functions!

Please refer to the AtMetadata class for the complete list of metadata attributes.

The focus of this article is on how to update the metadata of a key.

Description:

The update:meta verb is used for updating the metadata of a key. If a key is already present, the metadata is updated. If a key is not present, a new key is created with the given metadata with a ‘null’ value. Users can add the value using the update verb.

Please refer to update_meta_verb_handler for implementation.

SDK offers the ‘ putMeta’ method to update the metadata of a key.

Updating metadata of a key using the SDK.

var currentAtSign = '@alice';

//Creating AtClient SDK instance.
await AtClientImpl.createClient(
   currentAtSign, 'me', TestUtil.getAlicePreference());

// Getting atClient Instance
var atClient = await AtClientImpl.getClient(currentAtSign);

var metadata = Metadata()..ttl = 600000
                         ..ttb = 600000;
var atKey = AtKey()..phone
                   ..sharedWith = ‘@bob’
                   ..sharedBy=’@alice’
                   ..metadata=metadata;
var result  = await atClient.putMeta(atKey);

The AtClient exposes the ‘getMeta’ which can be used to get the metadata of the key. The ‘getMeta’ method returns metadata in a JSON String.

var currentAtSign = '@alice';

//Creating AtClient SDK instance.
await AtClientImpl.createClient(
   currentAtSign, 'me', TestUtil.getAlicePreference());

// Getting atClient Instance
var atClient = await AtClientImpl.getClient(currentAtSign);

var atKey = AtKey()
 ..key = 'phone'
 ..sharedWith = '@bob
 ..sharedBy = '@alice';
var metadata = await atClient.getMeta(atKey);

Response :

Metadata{ttl: 600000, ttb: 600000, ttr: null,ccd: null, isPublic: false, isHidden: false, availableAt : 2021-02-18 02:40:03.207Z, expiresAt : 2021-02-18 02:50:03.207Z, refreshAt : null, createdAt : 2021-02-18 02:30:03.207Z,updatedAt : 2021-02-18 02:45:03.207Z,isBinary : null, isEncrypted : null, isCached : false, dataSignature: null}

For more samples, please refer to update_meta_verb_test.

We are working to make the internet better. Please come code with us!!!

The monitor verb in the @protocol is used to stream the received notifications.

Please check the MonitorVerbHandler source code to learn more about the implementation of the monitor verb.

The article focuses on the usage of the monitor verb and how to filter notifications using regular expression(regex).

Description:

The monitor verb is used to stream the notification received from the other atsign user. Optionally a regular expression can suffix the monitor verb to filter the notifications. When regex is provided, only the notifications that match the regex are returned.

Example:

@alice notifying @bob

Var currentAtSign = '@alice';

var atKey = AtKey()
 ..key = 'phone'
 ..sharedWith = '@bob’
 ..sharedBy = currentAtSign;

var value = '+1 100 200 345';

var result = await atClient.notify(atKey, value, OperationEnum.update, notifier: 'system');

Monitor Verb running on @bob

await AtClientImpl.createClient(
   '@bob', '@persona', preference);
var atClient = await AtClientImpl.getClient('@bob’);
await atClient.startMonitor(preference.privateKey, _notificationCallBack);

Response

notification: {"id":"c6fab088-9e01-4374-a1da-182589eb8c7f","from":"@alice","to":"@bob","key":"@bob:phone@alice","value":null,"operation":"update","epochMillis":1613889831624}

notification: {"id":"c6fab088-9e01-4374-a1da-182589eb8c7f","from":"@alice","to":"@bob","key":"@bob:address@alice","value":null,"operation":"update","epochMillis":1613889831876}

Monitor Verb running on @bob with regex.

await AtClientImpl.createClient(
   '@bob', '@persona', preference);
var atClient = await AtClientImpl.getClient('@bob’);
await atClient.startMonitor(privateKey, acceptStream,regex: 'phone'
);

Response

notification: {"id":"c6fab088-9e01-4374-a1da-182589eb8c7f","from":"@alice","to":"@bob","key":"@bob:phone@alice","value":null,"operation":"update","epochMillis":1613889831624}

We are working to make the Internet better. Please come code with us!

At the moment dart compile only compiles self-contained executable files for the architecture it's being run on. This is a shame, as the underlying tooling is perfectly capable of doing cross compilation as J-P Nurmi explains in Cross-compiling Dart apps.

Without cross compilation the only alternative is to run dart compile from the Dart SDK on each of the target platforms. Google handily packages up the SDK into a Docker image google/dart but unfortunately that's only available for x86_64 (aka amd64). The Dockerfile for that image also makes use of the SDK apt package, but that too is only available for x86_64.

So to run dart compile on multiple architectures, I first needed a multi arch build image:

FROM debian:stable

ARG DART_VERSION="2.12.4"

WORKDIR /tmp/

RUN \
  apt-get -q update && apt-get install --no-install-recommends -y -q \
    gnupg2 curl git ca-certificates unzip openssh-client && \
  case "$(uname -m)" in armv7l | armv7) ARCH="arm";; aarch64) ARCH="arm64";; *) ARCH="x64";; esac && \
  curl -O https://storage.googleapis.com/dart-archive/channels/stable/release/$DART_VERSION/sdk/dartsdk-linux-$ARCH-release.zip && \
  unzip dartsdk-linux-$ARCH-release.zip -d /usr/lib/ && \
  rm dartsdk-linux-$ARCH-release.zip && \
  mv /usr/lib/dart-sdk /usr/lib/dart

ENV DART_SDK /usr/lib/dart
ENV PATH $DART_SDK/bin:/root/.pub-cache/bin:$PATH

This is installing some key dependencies (the same as google/dart) and then downloading and installing the Dart SDK according to the output from uname -m to establish the underlying architecture.

With the build image it's then possible to create a lightweight run image based on the work by Google engineer Tony Pujals with his subfuzion/dart-docker-slim:

# Originally based on subfuzion/dart-docker-slim
# Using our buildimage as it supports x64|arm|arm64
FROM atsigncompany/buildimage AS dart

# Do all the copying to an output dir here first
# as the buildimage has a shell that can be used
# for multi-arch conditionals
RUN \
  mkdir -p /output/lib && mkdir -p /output/etc && \
  mkdir -p /output/etc/ssl/certs && \
  mkdir -p /output/usr/share/ca-certificates && \
  case "$(uname -m)" in \
   armv7l | armv7) ARCH="arm-linux-gnueabihf" ; \
    mkdir -p /output/lib/$ARCH ; \
    cp /lib/ld-linux-armhf.so.3 /output/lib/ld-linux-armhf.so.3 ; \
    cp /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 \
       /output/lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 ;; \
   aarch64) ARCH="aarch64-linux-gnu" ; \
    mkdir -p /output/lib/$ARCH ; \
    cp /lib/ld-linux-aarch64.so.1 /output/lib/ld-linux-aarch64.so.1 ; \
    cp /lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 \
       /output/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 ;; \
   *) ARCH="x86_64-linux-gnu" ; \
    mkdir -p /output/lib/$ARCH ; mkdir -p /output/lib64/ ; \
    cp /lib64/ld-linux-x86-64.so.2 /output/lib64/ld-linux-x86-64.so.2 ;; \
  esac && \
  cp /lib/$ARCH/libdl.so.2 /output/lib/$ARCH/libdl.so.2 && \
  cp /lib/$ARCH/libc.so.6 /output/lib/$ARCH/libc.so.6 && \
  cp /lib/$ARCH/libm.so.6 /output/lib/$ARCH/libm.so.6 && \
  cp /lib/$ARCH/librt.so.1 /output/lib/$ARCH/librt.so.1 && \
  cp /lib/$ARCH/libpthread.so.0 /output/lib/$ARCH/libpthread.so.0 && \
  cp /lib/$ARCH/libnss_dns.so.2 /output/lib/$ARCH/libnss_dns.so.2 && \
  cp /lib/$ARCH/libresolv.so.2 /output/lib/$ARCH/libresolv.so.2 && \
  cp /etc/nsswitch.conf /output/etc/nsswitch.conf && \
  cp /etc/resolv.conf /output/etc/resolv.conf && \
  cp -R /usr/share/ca-certificates /output/usr/share/ca-certificates && \
  cp -R /etc/ssl/certs /output/etc/ssl/certs

FROM scratch
COPY --from=dart /output /
# Is this even really needed, as Docker uses host hosts?
COPY ./at-runimage/etc-hosts /etc/hosts

Once again this is using the output of uname -m to determine the correct dependencies to copy in from the build image.

The build image and run image can then be brought together with a Dart application. I put together a trivial one dartshowplatform that prints out version and platform information like:

$ sudo docker run -it  atsigncompany/dartshowplatform
2.12.4 (stable) (Thu Apr 15 12:26:53 2021 +0200) on "linux_arm64"

Here's the Dockerfile:

FROM atsigncompany/buildimage
WORKDIR /app
COPY ./dartshowplatform/showplatform.dart .
RUN dart compile exe /app/showplatform.dart -o /app/dartshowplatform

FROM atsigncompany/runimage
COPY --from=0 /app/dartshowplatform /app/dartshowplatform
ENTRYPOINT ["/app/dartshowplatform"]

The build image is used to run dart compile and then the binary created from that is copied into the run image.

The full source etc. for the stuff above is available on GitHub atsign-company/at_dockerfiles.

If you're wondering why we're doing this, it's because people are asking us to support Arm and Arm64, as there's huge growth in the Arm footprint as illustrated above. We can expect it won't be long before we're having to add RISC-V support too, as that Instruction Set Architecture (ISA) gains traction and wider adoption. The days of WinTel hegemony are over, which means dealing with a lot more heterogeneity, and that demands greater automation to avoid being drowned by the complexity of it all.

In order to do this, start by selecting the Text field type, under Custom Content. For the examples shown in this article, you can copy the code and replace the text in the asterisks with your own content.

HTML Tags

HTML Tags are like keywords that determine how a webpage should be displayed on screen. Most html tags come in two parts.

• An opening tag is used to mark the beginning of a section of page content. eg <html>

• A closing tag is used to make the end of a section of page content. eg </html>

Most tag types require the use of both opening and closing tags. However some do not, such as <br>. We will go over some of the tags that you might find useful when customizing your wavi weblet.

Positioning

To center your content like how this article is centered, the <center> tags can be used. Anything that is in between the tags will appear centered on the screen.

Code
<center> *your content here*</center>

Paragraphs and line breaks

There are two ways to create paragraphs and line breaks. The first way is by using <p> tags. When you enter a <p> tag, it will be handled as the beginning of a new paragraph.

Code
<p> *your content here* </p>

The second way is by using the <br> tag, which creates a line break in your content. You do not need to close this tag. A new line will be started on the content that follows the <br>.

Colored Text

If you want to add a pop of color to the text on your weblet, you can use CSS eg style="color:#00b7b8;" and <span> tags if you are only coloring specific parts of your paragraph.

Code
<p> <span style="color:#00b7b8;"> This text is teal colored </span></p>

Scrolling Text

To display a scrolling area of text, <marquee> tags can be used. These produce text that will scroll from one end of the text area to the other, indefinitely.

Code
<marquee> *your text here* </marquee>

This will display a single line of scrolling text.

Hyperlinks

To insert a link that has alternative text displayed on the screen, you can use <a> tags. The text in between the <a> and </a> tag is what will be displayed on screen.

Code
<a target="_blank" href="*your link here*">*your text here*</a>

Explanation

target="_blank" will open the link in a new tab.

href= specifies the URL of the page the link points to.

Images

Online images can be added to your wavi weblet using the <img> tag. The image must be accessible via URL. The source could be a website, a google image search or an image that you have uploaded onto an image hosting site like imgbb.com.

Code
<img width="100%" src="*your image url here*">

Explanation
width="100%" specifies the width of the image in relation to the screen. This can also be set in pixels eg "400px".

src="" specifies the URL for the image that will be displayed.

iFrames

An iFrame is a framed section in a web page that displays content from another web page. In the wavi app, you can use iFrames to display any non text content. This includes gifs, videos, images, audio players and even games.

The <iframe> tags are usually generated by websites when you select the option to share the website’s content via embedding. The general structure of the <iframe> tags is as follows.

Code

</iframe>```

**Explanation** <br>
src="" specifies the URL for the content that will be embedded into the iFrame.
width="" specifies the width of the iFrame
height="" specifies the height of the iFrame


Other attributes are usually added to the iFrame such as width and height specifiers. 

## Videos
<iframe width="100%" height="400" src="https://www.youtube.com/embed/NHDDQbsRHU8" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen="" enablejsapi="true" id="widget2"></iframe> 

In order to get the embed code for a video on Youtube, Vimeo or any other streaming service, you will need to be on a desktop. While on the chosen video, click share and then select embed in order to access the embed code. You can then transfer this code to your mobile device via email or other means.

Alternatively, you can use the sample iframe code provided below. Navigate to your chosen video and copy the video URL. If the URL is https://youtube.com/NHDDQbsRHU8 you only need the last part of the URL after the last / so in this case it would be just 'NHDDQbsRHU8'. Copy this and paste it into the iframe code after embed/ as shown in the example.

**Code** <br>
```<iframe width="100%" height="400" src="https://www.youtube.com/embed/*your video code here*" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen="" enablejsapi="true" id="widget2"></iframe> ```

## Music Players
<iframe src="https://open.spotify.com/embed/playlist/1vDhN0uiRxJiBR8JmZpnLl" width="100%" height="380" frameborder="0" allowtransparency="true" allow="encrypted-media"></iframe>

Playable music can be added from Spotify, Soundcloud and other streaming services. In order to get the embed code for a specific song or playlist, select share and then choose embed to access the embed code. Refer to the code below to gain an understanding of what the embed code may look like.

**Code** <br>
```<iframe src="*your playlist link here*" width="100%" height="380" frameborder="0" allowtransparency="true" allow="encrypted-media"></iframe>```

Once embedded, a music player will be displayed on the weblet. 

Depending on the streaming service, people may be required to login to their streaming accounts in order to play the music on your weblet.

## Gifs
<iframe src="https://giphy.com/embed/MeCyHmilLHIjWPcpWV" width="100%" height="480" frameBorder="0" class="giphy-embed" allowFullScreen></iframe><p><a href="https://giphy.com/gifs/tea-trex-loof-and-timmy-MeCyHmilLHIjWPcpWV">via GIPHY</a></p>

In order to add a gif to your weblet, you will need to find a gif online on a gif website like https://giphy.com/ . Once you have selected a gif, click on share or embed in order to access the embed code. You can then transfer this code to your mobile device via email or other means. The code will look something like this. 

**Code** <br>
```<iframe src="https://giphy.com/embed/MeCyHmilLHIjWPcpWV" width="100%" height="480" frameBorder="0" class="giphy-embed" allowFullScreen></iframe><p><a href="https://giphy.com/gifs/tea-trex-loof-and-timmy-MeCyHmilLHIjWPcpWV">via GIPHY</a></p>```. 

To remove the hyperlink that says via GIPHY beneath the gif, delete the ```<p>``` tags and everything in between them. 

Anything with an embed code can be added to your weblet using iFrames. 

Some examples include:
- Calendars
- Countdown timers
- Google docs, sheets and slides
- Code compilers and snippets
- Maps

The list is almost endless.

For inspiration, have a look at the sample weblets shown on [https://wavi.ng/@wavi](https://wavi.ng/@wavi).

Thankfully planningpoker.com also offers .csv import, and it's reasonably easy to generate a suitable file using some scripts that harness the GitHub API.

First we use listprojects.py to get the right project ID:

6018453 3 Used for tracking backlogs, bugs, issues, enhancements across multiple repo's in Open Source.
12437918 5 Open source development and sprint planning for https://atsign.dev.

Then list_project_columns.py to get the column name for the sprint we're planning:

11918750 Backlog
12092381 Bugs
14337222 PR12 - 107 SP's (Capacity 105)
13742763 Spike - POC

and lastly dump_project_cards.py to generate a .csv file that will look something like this:

Issue Key,Summary,Description,Acceptance Criteria,Story Points
38,Integrate Rocky's design into Docsy WTF site,,,
43,Home/landing page messaging and content,,,
40,Docs Page - Left hand menu items and flow,,,
41,Landing page design for each of main category pages in the top menu,,,
46,Open Source Policies & Process,,,
45,Update Nomenclature on Pub.dev and other pages,,,

The .csv file can then be imported into planningpoker.com, and all that tedious coping and pasting (and errors and omissions that might go with it) can be avoided.

The notify verb is a powerful method to send an encrypted data transmission to an @ sign’s secondary server, in this part of, “The Power Behind Sharing Data on the atPlatform”, we’ll be deep diving into just how the notify verb works and how to implement it into your own Flutter application.

What is the Notify Verb?

The notify verb is used to send data from one atSign’s secondary server to another atSign’s secondary server securely. It is a back-end developed verb that already exists so you as the developer do not have to worry about building it yourself! What this means is that all you have to do is choose what information you’d like to send to another atSign’s secondary server, pass this information through the parameters of the verb, and the atPlatform will take care of the messy parts, such as encrypting, transmitting and other headaches!

The Arguments of the Notify Verb

The verb itself can be seen with three main parameters; AtKey atKey, String value, and OperationEnum operation. The AtKey atKey is an object that contains the following member variables (or fields):

class AtKey {
// This is where the at_key itself will be stored
String key; 
// The @sign in which the information is
//  being passed to (can even be from yourself)
String sharedWith;
// The @sign in which the information
// is being passed from
String sharedBy;
// The namespace being the name of the 
// application where the information sent originates
String namespace;
// The metadata of the AtKey itself described 
// in another article
Metadata metadata;
// This boolean variable has not actually been 
// implemented from our backend just yet so stick around for updates!
bool isRef = false;

The String variable named value is actually the AtKey object being converged as a string, more on this later. Finally, we have our OperationEnum operation which is a very important part of the notify verb as this is the deciding factor of what type of notification will be sent to the chosen secondary server. You will see that the OperationEnum is defined as an enum (which is, in its simplest terms, a nice collection of constants) and in our case, the constants are; update, delete, append, and remove. What do these all mean, however?

When OperationEnum.update is passed through notify, the atSign who is receiving the notification will cache the value sent in either an already pre-existing version of the key and update the value with the new value sent, or create an entirely new key to store the value in. When OperationEnum.delete is passed through notify, the secondary server that has received the notification will then begin the process of deleting the cached key that was previously sent to them. Both the append and remove attributes have not yet been implemented by our backend team members, however, their functionality is still quite self-explanatory. OperationEnum.append will simply append the value to an already cached key and OperationEnum.remove will remove the specified value from an already cached key. Continue staying up-to-date with the atPlatform to see when append and remove have been implemented!

Now that all of the mandatory arguments have been discussed, when an atPlatform developer takes a closer look, they will notice that the notify verb also contains five other optional arguments! These arguments are; MessageTypeEnum messageType, PriorityEnum priority, StrategyEnum strategy, int latestN, and String notifier = SYSTEM. I won’t go into deep detail as to what these all are as some of them are quite complex, especially for a beginner developer. Regardless of the complexity of these arguments, we still endorse the brave-hearted to play around with them!

Implementing the Notify Verb in your Application

Now that you have a foundational understanding of what the notify verb is and what it is doing, it is time to start using it yourself! The notify verb is succinctly utilized in Atsign’s at_cookbook demo app and will be the main source of examples for this portion of the article. To give a summary of what the at_cookbook demo application is doing, it allows a testable atSign to create a cooking recipe with a recipe name, description, list of ingredients, and a picture. After doing this, the atSign is capable of sharing this entire recipe with another testable atSign. How did we do it? First, we created a dishWidget class that in itself would be an individual recipe with each instance. What we did was first initiate the fields:

// As you can see below, we have the recipe name,
// the ingredients, a description, the image and 
// a location for which screen was previously accessed 
// by the @sign within the app. 
  final String title;
  final String ingredients;
  final String description;
  final String imageURL;
  final String prevScreen;

// We didn’t want the @sign to be capable of passing any 
// of the recipe fields as blank
// [because who doesn’t want the full scoop  of the recipe!] 
// (no pun intended)
// So we made sure to list each field as required
  DishWidget({
    @required this.title,
    @required this.ingredients,
    @required this.description,
    @required this.imageURL,
    @required this.prevScreen,
  });

After retrieving all of these fields, we then push the entire dish widget as an object to the home screen where the list of recipes is located. Now that you have the recipe itself, you’re able to pass this through the notify verb. When an atSign wishes to share a recipe, all they have to do is press a button. On press of this button, a function titled _share is then called. This function is structured as so:

// Here, we’re initializing a variable called lookup as an AtKey object
// lookup will be our recipe
AtKey lookup = AtKey()

// You’ll notice that we’re defining a couple of the attributes of 
// the AtKey object, mainly the name of the recipe
    ..key = widget.dishWidget.title
//  What @sign is this recipe being shared with?
    ..sharedWith = atSign;

// Of course, we want to ‘get’ the values of our recipe, 
// so we use the get verb which exists in the 
// serverDemoService file of the application
String value = await _serverDemoService.get(lookup);

// ttr (Time To Refresh) being called with a value of -1 
// means that we’re confident that the values
// of our recipe won’t be changing, so once the recipe has been 
// cached on the secondary server that has received the recipe, 
// it will not need to worry about updating the values at any point
// The many fascinating attributes of MetaData will be covered 
// in an article part of this series later down the road!
var metadata = Metadata()..ttr = -1;
// After passing all of the necessary values such as the metadata,
// the appropriate @ signs and the type of notification we’d like
//  to send, we simply pass the values through the notify verb!
      AtKey atKey = AtKey()
        ..key = widget.dishWidget.title
        ..metadata = metadata
        ..sharedBy = atSign
        ..sharedWith = _otherAtSign;

      var operation = OperationEnum.update;
      await _serverDemoService.notify(atKey, value, operation);

If you would like to have a walkthrough on how we developed the at_cookbook demo app, feel free to watch Tyler Time Episode 3 on YouTube! If you have any questions, be sure to ask us on Discord!

When I try to do something new I’ve been following the same pattern for a decade

1. Do it in the GUI at least once
2. Do it manually in the CLI
3. Automate it with a script or declarative tool like Terraform
4. (If needed) build a declarative API for others to use

This roughly echoes my own approach to automation, but I've been noticing recently that sometimes I'm going straight to step 3 without even trying 1 & 2.

An example would be multi architecture builds for Docker images. We've been doing x86_64 builds for a while, but we also wanted to do 32bit and 64bit Arm for Raspberry Pis, Apple M1, AWS Graviton etc.

We were already using a GitHub Action to create the x86_64 image, and to get that working from the boilerplate below needed just a couple of things:

1. Create the secrets for DOCKERHUB_USERNAME and DOCKERHUB_TOKEN
2. Fill in the appropriate accountname, imagename and tagname for the tags: line

name: Docker

on:
  workflow_dispatch:

jobs:
  docker:
    runs-on: ubuntu-latest
    steps:
      -
        name: Set up QEMU
        uses: docker/setup-qemu-action@v1
      -
        name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1
      -
        name: Login to DockerHub
        uses: docker/login-action@v1 
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}
      -
        name: Build and push
        id: docker_build
        uses: docker/build-push-action@v2
        with:
          push: true
          tags: accountname/imagename:tagname
      -
        name: Image digest
        run: echo ${{ steps.docker_build.outputs.digest }}

To get the Action to make Arm images too all I needed to add was a platforms section after tags:

          tags: |
            accountname/imagename:tagname
            accountname/imagename:latest
            accountname/imagename:GHA${{ github.run_number }}
          platforms: |
            linux/amd64
            linux/arm/v7
            linux/arm64/v8

You'll see that I also added some extra stuff to the tags there to get :latest and a tag associated with the Action run number.

And that's all that was needed. Without ever trying to create a multi-arch image manually, I pressed the run button and it made me images for all 3 architectures. I can't actually imagine how doing it manually would be any easier - even for one iteration never mind for a repeatable system.

NB: I'm using on: workflow_dispatch: here whilst I test the Action, but soon enough it will be plumbed into the pipeline and running without human touch.

We are changing the Internet for good. Join us on

and code with us.

After a little Googling I found various scripts that use the GitHub API to manage labels. But nothing that seemed easy enough. So… I pulled together my own repo of scripts – atsign-company/labels , which we have now open sourced.

When a label is added to that repo it fires a GitHub Action that pushes the new label to all the repos listed in a config file (in our case atsign-foundation.yaml for our open source repos).

Thanks to Olivier Jacques for pointing me to the ability to start an Action from a labels event , and to the DXC DevOps Dojo team for having a nice labeling script as part of the Welcome module.

Please check the ScanVerbHandler source code to learn more about the implementation of the scan verb.

The focus of this article is to demonstrate how to filter scan verb results using a regex. Description If the regex is not specified, the scan verb will return all of the keys applicable to the person running the scan. Let's assume that an app running on the atPlatform is interested in only a subset of the keys. A regex can then be passed as part of the scan verb. When a regex is passed, the atProtocol’s secondary server ensures that only keys matching the regex are returned.

Sample Request:

scan ^@bob

This request scans all the keys which match with the regex ‘^@bob’

Sample Response:

data:["@bob:firstname@colin","@bob:location@colin"]

If you are using the SDK, use the following method.

await AtClientImpl.createClient('@bob', '@persona', preference);
var atClient = await AtClientImpl.getClient('@bob’);
List<AtKey> atKeys = await atClient.getAtKeys({String regex, String sharedBy, String sharedWith})

You can find the actual implementation here .

Coming Soon

We are working to make the Internet better. Please come code with us! Follow us on github https://github.com/atsign-foundation and join our developer community on Discord

%%[discord]

Configuring DNS masquerading Server

You have to first go to your virtual environment folder. If you follow the exact instruction from our getting started page until the advanced section your virtual environment folder will be in the User home folder. Such as in windows : C:\Users\ {Username}\ve . Now open up the “docker-compose.yaml” file in your favorite code editor. Uncomment the lines to enable your DNS masquerading server which can serve DNS and point the DNS address vip.ve.atsign.zone to the hosting PC/MAC/Linux machine.

Then to starts the Dns msq container run ‘docker-compose up -d’ in the terminal.

To find the IP address you need to run ifconfig/ipconfig based on which operating system you are running. Select the Ipv4 address starting with 192 and copy it. Then go to your local DNS Masq server: http://localhost:5380/

edit the address=/vip.ve. atsign.zone line to paste your IP address. Then save it.

Configuring Physical device

To configure the physical device, you have to go to the Wi-Fi setting. In android you have to change the IP settings from DHCP to static.

Then paste your IP address and save it. You can add as many devices as you want with this setup.

Enjoy developing in atProtocol !