Hello everybody.
I would like to introduce the “POI Horizon” platform that aims to provide a required ecosystem to store and manage POI (point of interest), query and inspect details and distribute already packaged data with a widget technique. To be honest, POI Horizon will evolve, the existing modules will get more functions and new modules will come as well. The widget will allow not only to distribute information from the ICP platform but the user will be able to operate with them, like vote on the favorite POI, choose the next “Web3 tour to launch” etc.
Let’s see some details below.
Key terms
Decentralized content bundle (or content bundle for short) – model to store various information. It is made up of one or more data groups. It is an internal term of the product.
Package – logical group of “bundles”. Packages are divided into public, private and shared and have various settings and limits which are specified during creation.
Toolkit app – UI application (frontend canister) to create/manage packages and bundles.
It is a visual entry point. It is also possible to manage packages/bundles via calling backend canisters from any programming language.
Explorer app – UI application to query details about any package/bundles.
Widget app – UI application to create/manage widgets where diffeent bundles could be included. Various widget types could be supported, more logic and options could be included
POI – point of interest. Any information could be represented as POI. But the initial intention is a declaration of the travel objects and related information.
POI Horizon – name of the ICP-based platfom. The former name (the initial one) was just “decentalized contentt bundle”. But the concept and opportunities and plans became more wider than just “bundle”. So, it is the main reason of introuding a new name
Project highlights
It is worth mentioning, POI Horizon is a new name, the initial name as “decentralized content bundle app”. The idea of the platform became wider and that is the reason of the new name.
Technically, POI Horizon is a set of backend services and UI applications. Right now we start from 3 visual applications, but the UI/UIX design will evolve, list of their functionalities will evolve and new modules will be added as well (frontend, backend). POI Horizon should become a “decentralized heart” of various applications.
POI Horizon utilizes the results of the previously developed solution ic-based-storage service (ics2). Actually, ics2 was re-organized a little and a core module (ics2-core) was declared and it is used as a dependency for ics2 and POI Horizon (ic-content-bundle)
Let me put github links here
- ics2-core : GitHub - sergeybykov85/ics2-core: Core package for the ICS2 service (ICP based storage service) https://github.com/sergeybykov85/ic-storage-service
- ic-storage-service (ics2) : GitHub - sergeybykov85/ic-storage-service: Storage service based powered by IC (https://internetcomputer.org/)
- POI Horizon (ic-content-bundle) : GitHub - sergeybykov85/ic-content-package: IC based solution to represent and handle various data types around POI (point of interest). This repository leverage the existing repo https://github.com/sergeybykov85/ic-storage-service
Backend services implemented with Motoko programming language. Recently source code was updated to be compatible with dfx 0.18.0 version
Tech stack for UI apps : Node.js, TypeScript, React, Vite & Vitest, ESLint & Prettier, SCSS
Simple illustration of the github repo
Concept and architecture
As it was mentioned, POI Horizon is made up of UI modules and backend services as well.
In some UI applications the user has to be authenticated to work with, but the explorer module should work without any authentication. Initially, the system supports only ICP-based authentication, but ethereum based authentication is waiting for its turn. So, sometimes in the future, an ethereum based user can authenticate himself, create a package, deploy some bundle, and be an owner of that physical canister etc.
The idea of UI application is providing an access for wide list of functionality of the platform.
For example, user is able to “deploy” a new canister (package entity) inside Toolkit app with a few clicks. Sure, if the user is authorized to do that and its “allowance“ is not reached. User can share public link to his just created package with anybody. Explorer app is available for everybody.
Here is a schema of existing canisters. This illustration refers to the current list of canisters and also some new possible modules mentioned as well.
A few words about each visual UI application.
Toolkit – application for the individual user to deploy a new package and submit new bundles. User is able to choose the proper options for its package. The package is divided into public, private and shared types. Public type means that anyone can contribute here. So, you can add new bundles into any public package. Private means that only you are authorized to work with. The shared type means that creator can work with (like a private type) and creator is allowed to apply (and modify) the list of contributors to work together. So, you can delegate the access to any identity and revoke it.
It is important to say, that even if there is a public package and you can add any new bundle here, it doesn’t mean that user is able to “touch” and edit the bundles were not created by himself
Explore app – application where authentication is not needed. It is a public app to check/find data, inspect any package or bundles.
Widget app – application for individual users to create a widget based on the supported templates and existing data. It is a way to embed “your package, your bundle(s)” or “any existing bundles” into the website. The list of supported templates will be extended from time to time based on the product needs and feedback. Also, the widget app allows to display information, execute CAT (call to action), request the user to vote on “various things” etc.
The nearest “new big module” is “incentive pools”. The aim of it is to encourage and motivate “data contributors”, but it is very very abstract definition. It is closly connected with toolkit app and explore app.
Access for the users
Explorer app
Any user can utilize an explorer application. Right now there is no authentication. If authentication become available for the explorer app, then the main aim of that is “convenience” like “ability” to see only your packages etc
Widget app
Users should be authenticated to work with the widget app. The main reason for the authentication is that the user creates a widget object inside this app and we have to link it with some identity. The initial vision is that users are free to use app, create/manage widgets etc. But the number of allowed widgets could be restricted per user account. Since more options will be available for the widget app (CAT opportunity , vote opportunity inside widget, analytics etc) , then, apparently, it might be possible to divide the access into groups like “free”, “basic”, “advanced” etc. Again, the basic opportunity to create/manage some widgets should be available for everyone.
Toolkit app
Users should be authenticated to work with the toolkit app. Users have the opportunity to deploy (create) own packages, add new bundles into them or add bundles into existing packages. Sure platforms pay some cost for such operations like new canister creation etc. Therefore the user can’t endlessly create new packages without any control. Toolkit app allows to specify “allowance” for any identity which means number of packages to deploy. Also , the toolkit app allows to specify “free tier” for any user, like “3 packages for any user”.
Just an example. On the configuation level I can set the allowance = 20 for user A, allowance = 30 for user B and “free fier = 3” for any user. It means, user A is able to deploy max 20 packages, user B = 30 packages, and any other user = 3 packages.
Irrespective of the “allowance” (which actually means max number of packages for the user ), any user can create bundles in the already existing packages if they are marked as Public package or Shared package (sure, user is should be inclluded as contributor for shared package)
Actually, we will apply a “high allowance” for the “Content team” that is responsible for content submission for various regions. Any user is able to work with the system as well because of the “free tier” (if it is activated).
I have to say, I want to avoid speculation when someone deploys a new package and does not create any bundle, so there is no value, only drain of cycles (fuel) for our platform. So, the platform has an opportunity to remove empty packages after some period of time. It is a “plan B”. Again, only empty packages could be removed! Since more options will be available for the toolkit app then, apparently, it might be possible to divide the access into groups like “free”, “basic”, “advanced” etc. Again, the basic opportunity to create new packages should be available for everyone, the opportunity to contribute to existing public packages should be available for everyone as well.
It is worth noting that new packages and bundles could be created without a toolkit app. It is possible to call backend services instead of using the ui app. Also, advanced users can deploy their canisters (bundle packages), upload data etc and then include all their packages into package_registry (sure, after getting the authorization to do that). Once the “such user’s package” is included into package_registry, then it is available for all existing UI apps like explorer, widget etc. Since we have some partnerships with other platforms where the IT department is available. So, sombody from IT department can utilize any programming language and call the methods to import their data 
Integrations with other applications
The primary goal of the POI Horizon is making a decentralized layer for other applications. It should be a self-sufficient ecosystem with UI entry points where people can contribute with their content, query/inspect any content, distribute them, participate in various decision making, getting rewards for the contribution etc. Existing platforms or future platforms can utilize the POI Horizon as a point of truth. In this case, individual users, or services that create/deploy a package or bundle remain the owner of the data. The other applications can only utilize this data, launch various rewards opportunities etc. The first candidate to utilize POI Horizon is “Web3 tour platform”. (https://web3-experience.com/)
Here is a simple slide of the relation between POI Horizon and Web3 tour application
Also, the another application “Web3 heritage” could be launched on top of the POI Horizon system. In this case, POI Horizon remains the core layer for other application.
It also mean, than functions and opportunities will evolve and growing for POI Horizon from time to time.
Just an one more illustration how the “camino messanger” (Camino is a travel industry blockchain) can be connected with Web3 tour and POI Horizon as well
Features
Deploy new package
Update package details
Create new bundle
Remove empty bundle
View bundle details, search opportunity
Submit bundle details , delete details
Create simple widget
Apply options on the widget
Widget rendering, widget items rotation, various sections inside the widget
Nearest Features
Management of the shared packages.
Shared package requires extra management of the conttributors. UI changes should be added to add/manage existing list of participants, review it in the explorer and toolkit app etc.
Wizard for widget management.
We assume that several widget formats will be supported. Right now backend model declares a lot of stuff for the search opptions. Also, backend model declares an option to control the output for the widget. A proper UI/UIX is needed to build widget search criteria, update it, apply extra options, preview settings etc.
Short-term plans
The nearest plan is simple :
- internal feedbacks and cosmetic changes for explorer tool
- UI pages to support managemet of the shared package because it is a frequently used scenario
- distribute the access between content team from various regions : Italy , France, Malta etc. Start training
- include “info pages” and “user guide dashboard” for the toolkit app
- support wizard mode for widget application to have a convenient way of settting the widget criteria
- support ethereum-based logic
- start integation (data pulling) for the web3 tour platform
Examples
Toolkit app
Here is some examples of the toolkit app
My packages
List of packages deployed by the user.
Deploy new package
If user is authorized to deploy a new package, then he/she sets the basic package details and some advanced options on demand.
List of all packages
Use can choose any package, review it and contribute with any bundle
Package page
User selects a package to add a bundle. Create bundle button is available only if user is authorized to work with the package
Explorer app
Here is some examples of the explorer app. As it was mentioned above, authentication is not needed here.
Home screen
Search by some criteria
Package details
Widget app
System will suppot various widget types in the future. Also, the user will be able to apply the custom settings on his/herr widget like “display tags”, “display gallery section” etc. Also, it will be possible to have some engagement inside the widgets like “vote on the POI”, “suggest some POI for web3 tour” etc.
Right now let’s see some current widget examples
Simple bundle widget
Simple bundle widget and comments
Simple test with embed code
Embed code of the widget is available in the bottom section of the preview page.
User can easy insert this html code to integate the widget with all data and behaviour into the website.
Right now, I take https://jsfiddle.net/ for my testing.
Widget can have more than one bundle. User can easy navigate over the items by clicking on the next/back items
Simple widget with audio guides
It worth mention that widget can be simle one and advanced as well. Widget is a way to distribute the previously created bundle objects. Also, extra options like CAT forr each bundle or “vote mechanism” could be added as well. I will be glad to demonstate it as well.
Sure, custom themes might be integrated to give some personalizations.
Conclusion
POI Horizon system is intented to be a layer zero for other platforrms like Web3 tour (https://web3-experience.com/) and Web3 Heritage (comming soon) and other. POI Horizon should support enough UI applications to inspect data, update data and distribute data. POI Horizon is a self-sufficient plattform, it is a core for other apps. The list of modules will be extended and the existing modules will get more featues and improvements… It is only a beginning. I hope, one more showcase will be submitted by Me soon…
explorer app: https://dazn3-cqaaa-aaaak-akosq-cai.icp0.io/