We and our partners use cookies on this site to improve our service, perform analytics, personalize advertising, measure advertising performance, and remember website preferences. By using the site, you consent to these cookies. For more information on cookies including how to manage your consent ...

Watch Live: Aston Villa v. Brentford - USANetwork.com

Watch Live: Chelsea v. Man United - USANetwork.com

MSA.Network

msanetwork

Imagine you're developing on your laptop, using Docker to containerize your applications for consistency and ease of deployment. Your current project involves using MinIO for object storage, and you've set it up beautifully in Docker. But here's the twist: your workflow requires MinIO to interact with a Flask application running on your localhost for processing events and executing functions (referred to as and in MinIO's context). Event Notifications Object Lambdas One of the common hurdles you might encounter in this setup is a networking-related error, typically manifesting as “ error (flask-notification:webhook): dial tcp 127.0.0.1:5000”…. This error is indicative of a fundamental networking misalignment between the Docker container where MinIO is running and the Flask application hosted on your localhost. Essentially, when MinIO inside Docker tries to send event notifications to the Flask app, it attempts to connect to localhost:5000. However, within the Docker context, localhost refers to the Docker container itself, not the host machine where your Flask app is running. This results in MinIO attempting to establish a connection with a service on localhost:5000 inside its container, where no such service exists, leading to the connection being refused. This scenario underscores the need for a clear understanding of Docker networking, particularly how localhost is interpreted differently inside a Docker container. This guide will subsequently delve into effective strategies to realign this communication, ensuring that MinIO inside Docker can successfully send event notifications to the Flask app running on your host machine. By addressing this challenge, we create a development environment that closely simulates a production setup, improving the reliability and effectiveness of your workflow. This walkthrough will guide you through the process of setting up this environment. We'll start by setting up MinIO within Docker, ensuring it's configured correctly to emit events. Then, we'll move on to the Flask application, designed to respond to these events. The crucial part of this guide will focus on enabling communication between the MinIO container and the Flask app running on your localhost. We'll tackle common hurdles such as Docker networking, address resolution and data consistency. By the end of this guide, you'll have a functional local development setup where , mimicking a production-like environment on your laptop. This scenario is not just about making things work; it's about creating a development environment that's as close to production as possible, enhancing the reliability of your development and testing processes. MinIO events trigger actions in your Flask app Understanding Docker Networking in Local Dev Strategies As we progress towards integrating our Flask application, it's imperative to first comprehend a crucial aspect of Docker networking - the communication dynamics between Docker containers and the host machine. This knowledge is particularly indispensable for developers orchestrating local development environments, such as on laptops, where there is a need for Docker containers and host services, like our Flask application, to interact without hiccups. The term ' ' within the context of a Docker container has a unique implication. Contrary to its usual reference to the host machine, inside a Docker container, 'localhost' points to the container itself. This distinction is of paramount importance, especially when Dockerized services, such as MinIO, attempt to reach services on the host machine. localhost To illustrate this point, let's consider an error scenario as shown in the following image: When MinIO, running inside a Docker container, fails to connect to the localhost – in this case, the Flask app on the host. The connection error we encountered in our Docker-MinIO screenshot, characterized by the message , initially appears complex. However, a closer analysis reveals its underlying cause. The segment flask-notification:webhook identifies the source of the issue – it's MinIO’s mechanism to interact with our Flask application. The phrase signifies MinIO's effort to establish a TCP connection with the Flask app, presumably located at . The critical part, , indicates that MinIO is unable to access the Flask app at the specified address, underscoring a fundamental challenge in containerized networking. (flask-notification:webhook): dial tcp 127.0.0.1:5000: connect: connection refused dial tcp 127.0.0.1:5000 localhost:5000 connection refused To correct this, a clear and direct communication pathway between MinIO and Flask is essential. For scenarios where Flask is hosted on the same machine but external to Docker, the solution involves configuring MinIO to connect to . This special DNS address acts like a direct line, enabling MinIO within its container to reach out to the Flask application on the host. host.docker.internal:5000 This offers a solution for Mac and Windows users through , a DNS name that allows containers to correctly reference the host, thus facilitating the desired interaction between containerized services and host-based applications. Understanding and utilizing this Docker feature is critical for ensuring that local development setups mirror production environments as closely as possible, thereby enhancing development reliability and efficiency. host.docker.internal Overview of Assets The foundation of our guide lies in the prepared assets available at the in the directory. Here I have provided the source code for anything discussed in this guide, at the heart of this repository, you'll find: GitHub minio/blog-assets repository docker_to_localhost This contains the relevant commands to preform the actions taken in Smooth Sailing from Docker to Localhost(this article). README File: README.md : This file constitutes the Flask application, serving as a crucial component in our setup. It is tailor-made to interact efficiently with the MinIO service. Flask App Files main.py : This is the blueprints for creating your Docker container. It defines the environment in which your Flask applications will be built and ran, ensuring consistency across different setups. Docker File for Flask App dockerfile : Acting as the orchestrator, this define how multiple containers (like MinIO and Flask) coexist and communicate within your Docker environment. Docker Compose File docker-compose.yaml Deploying Flask App for MinIO Event Handling In the context of integrating a Flask application with a Dockerized MinIO service, let's delve into the configuration of the Flask app. Specifically, I've set up a Flask endpoint with an identifier of that is intended to serve as the receiver for MinIO's webhook events via , as highlighted in the following screenshot: “flask-minio-event” http://host.docker.internal:5000/minio_event Below is the code for our demonstration Flask App that runs on our local machine and serves out a route of on : /minio_event port 5000 from flask import Flask, request, jsonify
import logging
import os
from dotenv import load_dotenv

app = Flask(__name__)

load_dotenv()
logging.basicConfig(level=logging.INFO)
I
@app.route('/minio_event', methods=['POST'])
def log_bucket_event():
    """
    Logs events received from MinIO to the Python logger.
    """
    event_data = request.json
    logging.info(f"Event received: {event_data}")
    return jsonify({'message': 'Event logged successfully'})

if __name__ == '__main__':
    port = int(os.getenv('FLASK_PORT', 5000))
    debug_mode = os.getenv('FLASK_DEBUG', 'False') == 'True'
    app.run(host='0.0.0.0', port=port, debug=debug_mode) In the previous section, we explored how Docker containers interpret 'localhost', which is a significant consideration in ensuring that the Flask app correctly receives notifications from a Dockerized MinIO instance. This Flask application in more specific detail, is configured to receive and log events from MinIO. The endpoint /minio_event is set up to listen for POST requests, which are expected to be the event notifications from MinIO. Note that the application runs on port 5000 and is configured to be accessible from all network interfaces (0.0.0.0), which is crucial for receiving requests from MinIO running inside a Docker container. Deploying MinIO Container with Docker Networking Deploying the MinIO container to interact with localhost services like a Flask API requires a specific Docker network configuration. This setup is crucial for enabling seamless communication between the container and your local machine, particularly for local development or testing scenarios. To achieve this, the MinIO container must be configured to use the host's network. This approach allows the container to directly interact with services running on the host machine, such as a Flask application. It's especially beneficial in development environments where the Flask app needs to access or store data in MinIO. The command for this configuration is straightforward yet powerful: docker run --name minio --network="host" minio/minio server /data Using the option removes the complexities of Docker's default network bridging and port forwarding. It's a simpler, more direct way to ensure that the MinIO container can access any service running on localhost, not just limited to the Flask app. This makes the MinIO container versatile for a variety of local services, streamlining the development and testing processes. --network="host" Deploying MinIO and Flask App Containers with Docker-Compose You can use Docker networking features, such as a custom network or Docker Compose, to facilitate communication between containers. By placing both containers on the same network, they can communicate using their container names as hostnames. Example using Docker Compose to facilitate the communication between a MinIO container named minio, and a Flask app container named flaskapp specified below as services: version: '3.8'
services:
  minio:
    image: minio/minio
    command: server /data
    ports:
      - "9000:9000"
    extra_hosts:
      - "host.docker.internal:host-gateway"
    networks:
      - mynetwork

  flaskapp:
    image: python:3.9 # Use an official Python image
    command: >
      sh -c "pip install Flask
      && FLASK_APP=main.py FLASK_RUN_HOST=0.0.0.0 flask run" # Install Flask and run the app
    volumes:
      - ./app:/app # Mount your Flask app directory
    working_dir: /app # Set working directory to your app directory
    ports:
      - "5000:5000"
    depends_on:
      - minio
    networks:
      - mynetwork

networks:
  mynetwork:
    driver: bridge This setup maps host.docker.internal to the host machine's IP address, allowing containers to access services on the host by adding the extra_hosts parameter. This setup allows MinIO to recognize host.docker.internal as the host machine, bridging the container-to-host communication gap. It's a smart workaround for a common Docker challenge, ensuring that MinIO can connect to services on the host, such as our Flask app. Additionally by including the Flask installation in the docker-compose file we will make the app listen on 0.0.0.0. This change is vital for accessibility from other containers and the host, broadening the communication scope of our Flask app. It’s an essential step for setups where Flask might also be containerized. The depends_on directive in the Flask service ensures an orderly startup sequence. By starting the Flask app only after MinIO is operational, we avoid potential timing issues. This arrangement mimics production environments where service dependencies are carefully managed, adding robustness to our local development setup. These examples are tailored for a Dockerized MinIO setup, ensuring effective communication with services running on the host. Be mindful of the security implications, especially when adjusting network settings or exposing ports, and choose the solution that aligns with your security and architectural requirements. Both methods will allow the MinIO service to communicate with your Flask application, depending on whether the Flask app is running on the host or inside another Docker container. Seamless Integration in a Dockerized World We've journeyed through the nuances of Docker networking, unraveling how to efficiently bridge Docker containers with localhost environments so a Dockerized MinIO service can effectively communicate with a Flask application running on your host machine. These insights are crucial for developers looking to harness the power of Docker without compromising on the flexibility and convenience of local development. Understanding Docker networking is more than a technical necessity; it's a step toward mastering containerized environments. The ability to set up and manage these interactions is a requirement in today's cloud-native development landscape. Whether you're developing on a laptop or deploying on a global scale, these skills ensure your applications remain robust, scalable, and secure. It's important to understand and implement best practices when developing cloud-native software. The Docker ecosystem is ever-evolving. You can quickly tap into the latest and greatest cloud-native technologies with an architecture based on containers and object storage. Stay curious and keep exploring. MinIO enables this exploration. Containerized, Kubernetes-native and S3 API compatible, MinIO frees you to write code that runs anywhere, consistently and reliably. Good luck on your journey with Docker and MinIO. May your development be robust, your solutions secure, and your learning continuous. If you have any questions we’re here to help, at or by joining the . hello@min.io Slack community

Smooth Sailing: Transitioning from Docker to Localhost

স্মুথ সেলিং: ডকার থেকে লোকালহোস্টে রূপান্তর

Reibungsloses Segeln: Übergang von Docker zu Localhost

Navegación tranquila: transición de Docker a Localhost

Navigation fluide : transition de Docker vers Localhost

सहज सेलिंग: डॉकर से लोकलहोस्ट में संक्रमण

順風満帆: Docker から Localhost への移行

원활한 항해: Docker에서 Localhost로 전환

Navegação suave: transição do Docker para o Localhost

Плавный ход: переход с Docker на Localhost

Sorunsuz Yolculuk: Docker'dan Localhost'a Geçiş

Thuận buồm xuôi gió: Chuyển đổi từ Docker sang Localhost

顺利进行：从 Docker 过渡到 Localhost

Nowadays, lots of people like to use containers to put their software on different computers. One of the most famous container tools is called Docker. Docker helps developers create, install, and run apps in a way that’s easy and fast. In this blog post, I will explore Docker containerization in depth, including its benefits, use cases, and how it works. What is Docker Containerization? ⚡ Docker is an open-source containerization platform that allows developers to package their applications and dependencies into a container. A container is a lightweight, standalone executable package that contains everything needed to run the application, including the code, libraries, system tools, and runtime environment. Containers provide a consistent and isolated runtime environment that ensures the application will run the same way across different environments. Docker containers are built using Docker images, which are essentially a snapshot of the application and its dependencies at a specific point in time. Docker images are created using a Dockerfile, which is a text file that contains instructions for building the image. These instructions include specifying the base image, copying files into the image, installing dependencies, and configuring the environment. Once the Docker image is built, it can be run as a Docker container on any system that has Docker installed. Docker containers are lightweight and portable, which means they can be easily moved between environments, such as from a developer’s local machine to a staging environment or a production server. Benefits of Docker Containerization ⚡ Docker containerization offers several benefits, including: Docker containers are highly portable, which means they can be easily moved between environments, such as from a developer’s local machine to a staging environment or a production server. This makes it easier to test, deploy, and manage applications across different environments. Portability — Docker containers provide a consistent and isolated runtime environment that ensures the application will run the same way across different environments. This helps to eliminate issues related to dependencies, system configurations, and other environmental factors. Isolation — Docker containers can be easily scaled up or down to meet changing demands. This makes it easier to manage resources and ensure that the application is running efficiently. Scalability — Docker containers are lightweight and use fewer resources than traditional virtual machines. This makes it possible to run more containers on a single host, which helps to reduce infrastructure costs. Efficiency — Docker containers provide an additional layer of security by isolating the application from the host system. This helps to prevent attacks and reduces the risk of security breaches. Security — Use Cases for Docker Containerization ⚡ Docker containerization can be used in a variety of use cases, including: Docker containerization is an ideal solution for building microservices-based applications. Containers can be used to isolate individual services and deploy them independently, which makes it easier to manage and scale the application. 1. Microservices Architecture — Docker containerization is a key technology in DevOps. Containers can be used to create a consistent and portable development environment that can be easily shared across teams. This helps to improve collaboration and streamline the development process. 2. DevOps — Docker containerization is a popular solution for deploying applications in the cloud. Containers can be easily scaled up or down to meet changing demands, which makes it possible to run applications more efficiently and reduce infrastructure costs. 3. Cloud Computing — Docker containerization is an ideal solution for implementing CI/CD pipelines. Containers can be used to create a consistent and portable build environment that can be easily integrated into the CI/CD process. This helps to improve the speed and efficiency of the deployment process. 4. Continuous Integration and Delivery (CI/CD) — How Docker Containerization Works ⚡ Docker containerization works by isolating applications and their dependencies into containers that can run on any system with Docker installed. In this section, I will explore how Docker containerization works in detail. 👉Docker Engine At the core of Docker containerization is the Docker Engine, which is the runtime environment that executes Docker containers. The Docker Engine consists of several components, including the Docker daemon, Docker CLI, and Docker API. 👉Docker Images Docker containers are built using Docker images, which are essentially a snapshot of the application and its dependencies at a specific point in time. Docker images are created using a Dockerfile, which is a text file that contains instructions for building the image. The Dockerfile includes instructions for: Choosing a base image: This is the starting point for the Docker image. It typically includes a base operating system and other dependencies needed to run the application. Installing dependencies: This includes any libraries or other packages needed by the application. Copying files: This includes copying the application code and any other necessary files into the image. Configuring the environment: This includes setting environment variables and other configuration settings. Once the Dockerfile is created, it can be used to build a Docker image using the Docker build command. The Docker image is then stored in a registry, such as Docker Hub, where it can be easily accessed and shared. 👉Docker Containers Docker containers are instances of Docker images that can be run on any system with Docker installed. When a Docker container is created, it is isolated from the underlying host system and has its own file system, network stack, and process space. Docker containers can be created using the Docker run command, which specifies the Docker image to use and any additional configuration options. For example, the following command creates a new Docker container using the nginx Docker image: docker run -d -p 80:80 nginx In this example, the -d option runs the container in detached mode, the -p option maps port 80 in the container to port 80 on the host system, and nginx is the name of the Docker image to use. 👉Docker Volumes Docker volumes are a way to persist data generated by a Docker container. By default, any data generated by a container is stored in the container’s file system, which is lost when the container is deleted. Docker volumes allow data to be stored outside of the container and shared between containers. Docker volumes can be created using the Docker volume command, which creates a new volume that can be mounted in a Docker container. For example, the following command creates a new Docker volume named mydata: docker volume create mydata Docker volumes can be mounted in a Docker container using the -v option with the Docker run command. For example, the following command creates a new Docker container named myapp and mounts the mydata volume in the /data directory in the container: docker run -d -v mydata:/data myapp In this example, the -v option specifies the name of the Docker volume to mount and the directory in the container where it should be mounted. 👉Docker Networks Docker networks allow Docker containers to communicate with each other and with the outside world. By default, Docker containers are isolated from each other and can only communicate through a shared file system or by mapping ports to the host system. Docker networks can be created using the Docker network command, which creates a new network that can be used to connect Docker containers. For example, the following command creates a new Docker network named mynetwork: docker network create mynetwork Docker containers can be connected to a network using the — network option with the Docker run command. For example, the following command creates a new Docker container named myapp and connects it to the mynetwork network: docker run -d --network mynetwork myapp In this example, the — network option specifies the name of the Docker network to connect to. 👉Docker Compose Docker Compose is a tool for defining and running multi-container Docker applications. It allows developers to define their application as a collection of services, each of which is defined by a Docker container. Docker Compose uses a YAML file to define the services and their configuration. The YAML file includes: The Docker images to use for each service The configuration options for each service, such as ports, volumes, and environment variables The dependencies between services For example, the following Docker Compose YAML file defines a simple multi-container application that includes a web service and a database service: version: '3'
services:
  web:
    image: nginx
    ports:
      - "80:80"
  db:
    image: mysql
    environment:
      MYSQL_ROOT_PASSWORD: password In this example, the web service uses the nginx Docker image and maps port 80 in the container to port 80 on the host system. The db service uses the mysql Docker image and sets the MYSQL_ROOT_PASSWORD environment variable to “password”. Docker Compose can then be used to start the application using the Docker-compose up command, which creates and starts all of the services defined in the YAML file. 💎 Conclusion Docker containerization is a cool tool that can help you pack and run your apps smoothly. It can put your apps and all the things they need into . With Docker, you can create a stable environment for building and testing your apps, and then you can easily install them on any computer that has Docker installed. containers In this blog, I have explored how Docker containerization works, including the Docker Engine, Docker images, Docker containers, Docker volumes, Docker networks, and Docker Compose. With this knowledge, developers can begin to build and deploy their own Docker applications with confidence. Hope you find this article insightful 😉 💚 Also Published Here ✨ Follow me on - YouTube — https://www.youtube.com/@theritikchoure/ LinkedIn — https://www.linkedin.com/in/ritikchourasiya/ Twitter — https://twitter.com/theritikchoure

Docker Containerization: The Ultimate Guide

IMAP Email Server on AWS

Imagine you’re a venture capitalist in the 1960s. You’ve got money to invest and you’re presented with two pitches. The first is for a device that works just like a Star Trek communicator. You can video chat with friends and loved ones all around the globe. Instant face-to-face communication with anyone on Earth right in your pocket. The other pitch is for text messaging. Now who gets the money? In the competition between phone calls, video chat and text messaging, nobody would have guessed that Americans of the 21st century would be five times more likely to text than call on the phone. And video chat is mostly relegated to employer-related Zoom calls or the occasional hello to aging relatives in another state. As of 2021, less than half of all internet users polled made any video calls at all in the previous month. This is the exact opposite of what would have been expected back when Star Trek first came out. And though this result could probably have been predicted with a few days of user testing back in 1966, nobody apparently bothered to test because video chat just seemed like the future. It was too cool not to be the future. But the future doesn’t care about cool. The future works kind of like evolution, in the sense that it has nothing to do with perfection or improvement or what’s cool. It’s about adapting to circumstances. What might at first seem like limitations are actually text messaging’s strongest benefits. It’s almost completely free from the cognitive burdens created by the sort of face-to-face human interaction that a video call simulates. There’s none of the formal acknowledgement of each other, none of the required ‘what have you been up to?’, none of the non-verbal cues that you have to be aware of sending and receiving during every moment of a video — let alone face to face—interaction. Texting just makes your life easier. And at the end of the day, for technology to be widely adopted, it needs to make our lives easier, better or more fun. Enter the Metaverse. It’s all the rage and billions are being spent on it, but is it going to end up little more than the video chat of the 21st Century? Will the Metaverse become an integral part of our daily lives like texting, or be wheeled out every generation or so like 3D TV to a brief wave of excitement followed by years of general apathy and neglect? First of all, the Metaverse isn’t one thing, it’s an overarching concept that includes all sorts of different things, some of which might succeed while others fail. It could very easily Balkanize into a half dozen moderately lucrative niche markets (which might test the definition of the word ‘Metaverse’ but then the future doesn’t care about definitions either). As far as human activities that might get ported to the Metaverse, you’ve got gaming of course, but also buying and selling, flirting and dating, all kinds of job-related interactions and services, local politics, and the long sought after ‘third place’ for hanging out that Starbucks or your local pub might provide. We know gaming will be successful because it’s already succeeded. Fortnite is basically a small, constantly cycling Ragnarok Metaverse where everyone kills each other, and it has become the most successful game on Earth, with a cumulative playtime of over 10.4 million years (which is the length of time modern Homo Sapiens have existed on Earth times 34 —nobody’s betting against gaming). So sure, that works, but we do have to ask the question ‘what about the other stuff?’ If you aren’t hoping to slake your bloodlust in a societally-acceptable manner, will you even bother to log in to whatever passes for the Metaverse five years from now? One way to unravel that would be to look at some early examples, like Second Life. Nobody seems to want to admit this, but Second Life, a platform where your avatar can wander around aimlessly in a virtual browser-based world, has been around for over 15 years. If the Metaverse is so great, why aren’t we all living in Second Life right now? At the time of its creation, Facebook was little more than a twinkle in the eye of the coed-rating Harvard student and yet Facebook currently has roughly 45 times Second Life’s user base. Why does Mark think a metastasized version of this early oughts relic is the future of the internet? It might be the true three dimensional experience that can be had through headsets like Meta’s Quest. But is the addition of an extra dimension enough to help Second Life 2.0 take over the world? Another possible reason for Mark’s excitement could be the bounty of data that can be mined from human beings whose every movement, eye blink and intake of breath is being recorded, as they traipse around a virtual boardwalk or interview for a job with their heartbeat serving as a virtual lie detector. Imagine if Facebook was a full body wetsuit that data-mined everything you did or said as you went about your daily life. Seemingly that’s the apotheosis of the Metaverse from a marketing perspective, and that would absolutely be worth the multi-billion dollar cash spigot Zuckerberg constructed in order to make that vision a reality. So sure, his motivation makes total sense, but for the billions of us who aren’t him, that’s probably not a Metaverse we’d want to live in. Luckily, other people are positing a more decentralized experience that could use blockchain technology, interoperability and sovereign identity to sidestep the dangers that a walled garden like Meta presents. And yet, even that does not answer the question of whether —at this point in time— people will actually show up. If you want to predict a given activity’s likelihood of success when ported to the Metaverse, I think you have to apply a logical sieve based on how well our currently available technology can address the basic human need for simplicity, comfort or engagement. Which leads to three constraints of the Metaverse, circa 2023: 1.0  You will not get mass adoption for any behavior that is easier, better or more fun to do somewhere else. This is user testing 101, but the reason lame-ass texting beat out supercool video chat is because texting makes your life easier. We didn’t want phone calls to be more like real life, it turns out we really needed them to be more like handwritten notes. In retrospect this should have been obvious, but this is the sort of lesson that technocratic society seems to need to relearn every five to seven years. Remember Juicero? This was a wifi connected juicer that provided proprietary, single-serving packets of pre-chopped fruits and vegetables sold exclusively by subscription. Tech people gave this startup $120 million dollars in human money before a YouTube video showing how you could just squeeze their packets yourself destroyed their entire business model. It failed because there was an easier and cheaper way forward. 2.0  Just because it’s cool doesn’t mean people want it. 3D video is cool. But for a host of reasons such as lack of color vibrancy, user headaches, limited viewing angles, and the fact that parallax isn’t that noticeable beyond 13 feet, it’s not yet cool enough for your average consumer to bother with. It might work someday, but that day keeps getting pushed back, year after year. And remember a while back when snorting atomized chocolate was a thing? Probably not, because it was yet another of those interesting ideas that no one asked for, needed, or wanted, and it disappeared after one news cycle. In fact, it’s super easy to sit in a room with your fellow thought leaders and Dungeon’s & Dragons yourself a collective narrative where everyone relates to each other in a perfect virtual world, but if the reality of the situation at this moment in time is frustrating or tedious, nobody’s going to log on. It doesn’t have to be super high resolution or zero latency or achieve any other technical baseline, it just has to conveniently address a basic human need better than whatever people are doing at the moment. 3.0  No one is going to wait around for you to get your shit together Remember the Apple Newton? You probably don’t because statistically speaking you’re like 23 years old, but the Newton was one of the first digital assistants. It was essentially the ‘cave drawing’ version of an iPhone. It had one percent of the functionality in the form factor of a desktop computer’s power brick. In this case, the folks at Apple likely understood what we all wanted and needed, but they were sorely unable to deliver it because consumer tech couldn’t yet support their vision. You know what worked better than an Apple Newton? The tiny spiral-bound notebook I kept in my back pocket for phone numbers. And this, in the end, could be the biggest threat to 2023’s version of the Metaverse, the danger that our brilliant vision of the future could be hobbled by the limitations of the age. It’s very easy to imagine a cyberpunk world and to convince yourself that you’re building an on-ramp toward it, but if you’re programming for that future while your product looks like bad Flash animation from the early 2000s, you’re going to have a hard time getting my mom to sign up. Perhaps the best way forward at this particular juncture would be to take a hint from the success of text messaging and suss out those areas where our current technical limitations are a feature rather than a bug. I think you have to ask, in which behavioral circumstances does the simplicity of the low-res three dimensional avatar-based interaction model prove more useful or fun for people than their current popular use cases? Take romance for example. If you want people to hook up inside the world you’re building, your competitors aren’t other Metaverses, it’s Bumble, Hinge, , etc. You have to provide an environment that addresses those companies’ Web 2.0 limitations without introducing new ones of your own. Match.com Maybe you’re imagining a kind of futuristic meta-cafe where anyone can log in and hang out. But remember Chat Roulette? There are some intrinsic problems to this format, even if your avatar doesn’t have a penis. Just because you’re building the future doesn’t mean that the requirements of the human use case will suddenly disappear. You’re going to need to know who people are and what they are like. And it’s a heartwarming human interest story if some person from Uruguay discovers true love with someone from Srebrenica, but most of us don’t want to work that hard. When I was single and living in the Silverlake area of Los Angeles, a woman from Santa Monica was geographically undesirable, let alone Estonia. To beat out Tinder, your cyber cafe will need to improve on their baseline functionality. You’ll want geolocation and interest filters, and if you are serious about addressing the romance market, you’ll need user photos in addition to avatars. Sure, true love is the perfect melding of two souls blah-blah-blah, but I’m guessing your average 24 year old coed is not prepared to commit herself to a purple bunny avatar belonging to Marcus the 62 year old bail bondsman with limited mobility and three estranged kids. The Metaverse could beat out the Tinders of the world by providing a gentle onramp, not to any cybertech future, but to real world interaction. Your meta cafe could serve as a low stakes environment where folks who live relatively close to each other could log in and work to achieve some kind of collective goal, play pub games or contribute to common interests. You know how kids will get together and play with dolls or action figures, creating scenarios and conversations on the fly? This is the adult version of that. It might sound simplistic, but these days it seems like we could all use a little remedial education in how to socialize. The limitations of our  low res 3D environment could be beneficial to engagement in this scenario, perhaps providing a less anxious intermediate state between an in-person blind date, which can seem like a job interview for getting laid, and the cold brutality of a swipe left. In fact, what this sounds like, apart from the getting laid aspect, is Roblox, the social media gaming platform that already has approximately 1.3 million years of collective gameplay under its belt. Of course Roblox is a walled garden and focuses on the youth market, but sooner or later those kids are going to grow up, and so the Roblox folks could very well be positioning themselves for a future of mass adoption. The danger of course would be that they might become the America Online of the real Metaverse and be left behind by subsequent innovators such as Sandbox or an even less centralized competitor (if you’re under 30, just Google ‘America Online CD’). At the end of the day, whether it’s dating or selling shoes, no one is going to sit and wait for technology to catch up with your William Gibson dreams, so if you want people to log in to the Metaverse right now, in an attempt to address the non-gaming realms of human need, you’ll probably want to work on small improvements to the Web 2.0 status quo rather than attempt to build the world that we ultimately all want but won’t have the technical chops to deliver for another decade or so. The alternative is to become the Metaversical equivalent of my 3D LG TV, which has been used stereoscopically maybe a dozen times, playing Cars 2 and Killzone for an audience of one. Reference: https://slate.com/technology/2022/02/second-life-metaverse-facebook-comparisons.html https://www.statista.com/statistics/1254856/mobile-video-calling-age-gender-distribution/ https://mixnetworks.com/45-stats-on-how-video-calling-brings-us-closer/ https://www.forbes.com/sites/brucelee/2017/07/05/snorting-chocolate-is-now-apparently-a-thing-but-why-would-you-do-it/?sh=383d0149f900 https://gamerant.com/fortnite-most-played-game-ever/ https://en.wikipedia.org/wiki/Juicero https://www.lifehacker.com.au/2016/05/why-3d-tv-failed-and-why-we-dont-care/ https://www.demandsage.com/how-many-people-play-roblox/ https://www.inverse.com/input/culture/chatroulette-swears-it-solved-its-unwanted-pervert-problem

Three Constraints of the Metaverse

21st century -the internet age, is all about digitalization and fast movement of stuff from one point to another. Social media platforms are one of the internet sensations of the modern era of the internet. Facebook and Twitter are the top social media platforms having millions of user base. By nature, these platforms require a lot of personal information from the user, hence raising the issue of privacy and security at the hands of a centralized platform, controlled by a big corporation. In recent years scandals of user data leakage and privacy emerged on the mainstream media. Facebook was accused of selling or misusing essential user data that lead to several issues of identity theft and other related problems. With company share price tumbling and numerous lawsuits, Facebook CEO Zuckerberg had to present himself to Congress where he had to answer the questions related to data harvesting scandal. A significant problem with centralized networks like Facebook and other mainstream social media is that there is only one party controlling or responsible for all the user data and actions by the user, thus raising issues of privacy and security. These issues of privacy, freedom, and lack of control at the user's end gave rise to a new form of social networks, i.e., Decentralized Social Networks, - A network controlled and managed over distributed systems rather than one single entity. This concept gave rise to new social networks that are now very popular and have a vast user base. One of the main reasons for the popularity of Decentralized Networks is decentralized blockchain technology. This was one of the leading causes for people feeling secure using crypto and other digital currencies as they thought the technology is safe and not controlled by a single centralized identity. In this article, we will discuss top Decentralized Social Networks with their main features and advantages. Top decentralized Social Networks 2019 is one of the top Decentralized Social Media network having millions of user base, using the system on Distributed Database Network. Diaspora: Diaspora introduces itself based on three main principles. •    Decentralization — Network runs on independent distributed serves and is not centrally owned by a corporation. •    Freedom — It's not compulsory to reveal all your private information like a phone number. •    Privacy — User owns the data and is not forced or advised to use it on the platform. is one the modern day platform that you can say has revolutionized the concept of, user-owned platforms. With zero censorship of the network, the user owns everything. Minds: Even the code is open source, and users can make changes in it. It has features of all modern platforms like Facebook, Twitter, and YouTube and is getting popular day by day with a user base of over 2 Million. Minds is a great enforcer of freedom of speech and encourage it through its features; nature and by relying on core principles of liberty and privacy of its users. Imagine a platform having all the features of general social media with the addition of you getting revenue and rewards from it. This is how all.me is revolutionizing and changing trends in the world of decentralized social networks. All.me : All.me comprises primarily of four main modules: •    Social network (meNetwork) – Users interacting over distributed social media platform •    Marketplace (meMarket) – Buying and selling platform for users •    Payment service (mePay) – Payment service to make safe and secure online purchases •    Cryptocurrency (meToken) – The network has its digital currency for transactions With new and advanced features like a proper market place and combining blockchain technology with a social media network. All.me is going to be one of the top systems you can sign up to. is open source software like twitter but running on independent servers. This ad-free network allows you to control who can see your message and posts. Mastodon : To avoid annoying the users and keeping it free from ads, the network is fueled on donations. User's interaction with the platform is strictly monitored by moderators, and they jump in if there is an issue. Did you ever get annoyed by seeing videos or posts on social media that you are not interested in? Sola aims to provide a solution to this problem, by using AI and advanced technology it seeks to target content based on user interest and thus ensuring more engagement on posts and content reaching the right audience. Sola: Sola is not an ad-free platform, but It makes sure it gives the opportunity of monetization to its users. It is converting quality content into revenue streams. The list doesn't end here, and there are a lot of other platforms that are making their place on the internet. As discussed earlier, the recent scandals of data harvesting Facebook caused a significant backlash, and users even started deleting their accounts. It is rumored that almost every top social media is involved in selling user data to advertising companies who in return, use that data to bombard users with ads. Decentralized Social Networks – Solution to the Problem Users on the internet want to feel safe while using it. Centralized Social media platforms have failed to provide users a secure and reliable system in the recent past, and this led to a vacuum that is now being filled by decentralized networks. These networks are secure and solely based on the concept of freedom and control being held by the user. As social media networks are now evolving every day, the risk of privacy and user data concerns are also increasing. Users are now aware of privacy concerns, and they prefer a platform that doesn't ask for their personal information or keeps it safe. Traditional social media has now also introduced the opportunity of monetization for users, but again being a convenient form of media, they have to cut their commission and then reward the user. Decentralized networks noticed this weakness and being decentralized they reward users with more opportunity of revenue streams then the traditional social media. Although it might be too early to say, seeing user's changing interest over time, decentralized Social Media is all set to take over the world of social media soon.

Best Blockchain Based Decentralized Social Media Sites

Hyperledger Composer architecture Welcome, to part two of the “Choosing private blockchain tech” series ( ). In each article we implement a simple use case to give an overview of what an existing technology does and how it can be useful in businesses. part1 is here Originally, this article was meant to be about Hyperledger Fabric, but after learning about Hyperledger Composer, it became clear that it would be beneficial to write about it first. This will allow us to get a higher-level view of what type of business applications can be built on top of Hyperledger Fabric blockchain and make it easier to understand the purpose of Fabric itself. The business use case Let’s start with the artificially simple use case from the finance industry defined in . Here are the parties in this scenario: part1 makes investment decisions (trades). Non-custodial means they don’t actually hold a client’s money. Instead, after a trade is executed they send directions to a custodian that moves the money appropriately. Non-custodial asset manager (hedge fund): : Usually a large and trusted finance institution that holds a client’s money and executes transfers on behalf of the hedge fund. A custodian needs to know about each trade to distribute payments to counterparties. Custodian : Invests into the hedge fund. Each client needs to view trades in their own account, but not other clients’ accounts. Client(s) Let’s see how we can use Hyperledger Composer to define all participants in this scenario and enable them to share appropriate information. What is Hyperledger Composer? Hyperledger Composer is a higher-level toolset and framework made to quickly build and run applications on top of Hyperledger Fabric blockchain. If Fabric is network-level, Composer is application-level. It allows us to define the data model, business logic and access control lists for an application that can be deployed and executed inside of a . Users of such applications don’t have to run a local node and can interact with a remote node through an RPC or HTTP REST if needed. Fabric channel Composer comes with a nice which allows users to prototype applications in browser without setting up a local network. We’ll use the playground to implement and test our use case. In a future article, we will export the resulting ‘business network definition’ and deploy to a real Hyperledger Fabric blockchain. web playground Solution The full code of the solution can be found . Bellow we’ll see how to configure each piece step-by-step using the . here Composer Playground 1. Create network Select ‘Deploy a new business network’ and fill out the required info. In my case, the name of the network is ‘hedge-fund-network’ and admin card name is admin@hedge-fund-network. Select the ‘empty-business-network’ template and hit Deploy. This will create an empty business network and an admin identity that has full control over it. After the business network is created we can connect to it by pressing ‘Connect Now’. 2. Configure object model Composer has its own object modeling language that is very straightforward and easy to use. There are 4 types of resources that can be defined: . Things that are being tracked in the application. In our case we track Lots — traded blocks of securities. Assets Entities that interact with the network. Each has their own permissions. Participants. are sent to update an asset or a participant as well as to execute a custom-defined logic. Transactions can be emitted from the transaction logic and subscribed to by participants. Events Now, let’s create a model file named ‘org.acme.mynetwork.cto’ and add the following code. The file defines 3 participant types (Trader, Client, Custodian), Lot asset, Trade transaction and NewTrade event. /*** My commodity trading network*/namespace org.acme.mynetwork asset Lot identified by lotId {o String lotIdo String securityNameo Double quantityo Double price--> Client owner} participant Client identified by clientId {o String clientIdo String description} participant Custodian identified by custodianId {o String custodianIdo String description} participant Trader identified by traderId {o String traderIdo String name} transaction Trade {--> Trader trader--> Client client--> Lot lot} event NewTradeEvent {--> Lot lot} 3. Configure transaction logic Next, we’ll implement a custom logic that gets executed every time a Trade transaction is sent. Create a new script file called script.js with the code below. Composer knows to execute this code for each Trade transaction based on the @param annotation in the comment. This code does 2 things: changes the owner of a Lot and emits a NewTrade event on success. /*** Track the trade* {org.acme.mynetwork.Trade} trade — the trade to be processed* */function tradeCommodity(trade) {var factory = getFactory();trade.lot.owner = trade.client;var result = getAssetRegistry(‘org.acme.mynetwork.Lot’).then(function (assetRegistry) {return assetRegistry.update(trade.lot);});if (result) {var newTradeEvent = factory.newEvent(‘org.acme.mynetwork’, ‘NewTradeEvent’);newTradeEvent.lot = trade.lot;emit(newTradeEvent);}return result;} @param @transaction 4. Access control list (ACL) Lastly, we need to define an access control list governing what each participant type can do and see. Here we specify that traders can execute trades, clients can view their own trades, and custodians can view all trades. /* Admin */ rule NetworkAdminUser {description: "Grant business network administrators full access to user resources"participant: "org.hyperledger.composer.system.NetworkAdmin"operation: ALLresource: "**"action: ALLOW} rule NetworkAdminSystem {description: "Grant business network administrators full access to system resources"participant: "org.hyperledger.composer.system.NetworkAdmin"operation: ALLresource: "org.hyperledger.composer.system.**"action: ALLOW} /* Common */ rule CommonReadTransactionRegistry {description: "Allow all participants to read transaction registry"participant: "org.hyperledger.composer.system.Participant"operation: READresource: "org.hyperledger.composer.system.TransactionRegistry"action: ALLOW} rule CommonReadParticipantRegistry {description: "Allow all participants to read participant registry"participant: "org.hyperledger.composer.system.Participant"operation: READresource: "org.hyperledger.composer.system.ParticipantRegistry"action: ALLOW} rule CommonReadAssetRegistry {description: "Allow all participants to read asset registry"participant: "org.hyperledger.composer.system.Participant"operation: READresource: "org.hyperledger.composer.system.AssetRegistry"action: ALLOW} rule CommonReadNetwork {description: "Allow all participants to read network"participant: "org.hyperledger.composer.system.Participant"operation: READresource: "org.hyperledger.composer.system.Network"action: ALLOW} /* Trader */ rule TraderManageClient {description: "Allow traders to read all clients"participant: "org.acme.mynetwork.Trader"operation: ALLresource: "org.acme.mynetwork.Client"action: ALLOW} rule TraderManageOwnTrades {description: "Allow traders to manage their trades"participant(t): "org.acme.mynetwork.Trader"operation: ALLresource(tt): "org.acme.mynetwork.Trade"condition: (tt.trader.getIdentifier() == t.getIdentifier())action: ALLOW} rule TraderManageLots {description: "Allow traders to read and create lots"participant: "org.acme.mynetwork.Trader"operation: READ, CREATEresource: "org.acme.mynetwork.Lot"action: ALLOW} rule TraderUpdateLots {description: "Allow traders to update lots via Trade transaction"participant: "org.acme.mynetwork.Trader"operation: UPDATEresource: "org.acme.mynetwork.Lot"transaction: "org.acme.mynetwork.Trade"action: ALLOW} rule TraderReadOwnTrader {description: "Allow traders to read their own info"participant(t): "org.acme.mynetwork.Trader"operation: READresource(tt): "org.acme.mynetwork.Trader"condition: (tt.getIdentifier() == t.getIdentifier())action: ALLOW} rule TraderAddAsset {description: "Allow traders to add assets to registry"participant: "org.acme.mynetwork.Trader"operation: CREATEresource: "org.hyperledger.composer.system.AddAsset"action: ALLOW} rule TraderCreateHistorianRecord {description: "Allow traders to create historian record"participant: "org.acme.mynetwork.Trader"operation: CREATEresource: "org.hyperledger.composer.system.HistorianRecord"action: ALLOW} rule TraderReadOwnHistorianRecord {description: "Allow traders to read their own historian record"participant(t): "org.acme.mynetwork.Trader"operation: READresource(hr): "org.hyperledger.composer.system.HistorianRecord"condition: (hr.transactionType == "org.acme.mynetwork.Trade" && hr.participantInvoking.getIdentifier() == t.getIdentifier())action: ALLOW} /* Client */ rule ClientReadOwnTrades {description: "Allow clients to view their trades"participant(c): "org.acme.mynetwork.Client"operation: READresource(t): "org.acme.mynetwork.Trade"condition: (t.client.getIdentifier() == c.getIdentifier())action: ALLOW} rule ClientReadOwnEvents {description: "Allow clients to subscribe to NewTrade events"participant(c): "org.acme.mynetwork.Client"operation: READresource(e): "org.acme.mynetwork.NewTradeEvent"condition: (e.lot.owner.getIdentifier() == c.getIdentifier())action: ALLOW} rule ClientReadOwnLots {description: "Allow clients to view lots they own"participant(c): "org.acme.mynetwork.Client"operation: READresource(s): "org.acme.mynetwork.Lot"condition: (s.owner.getIdentifier() == c.getIdentifier())action: ALLOW} rule ClientReadOwnClient {description: "Allow clients to view their info"participant(c): "org.acme.mynetwork.Client"operation: READresource(cc): "org.acme.mynetwork.Client"condition: (cc.getIdentifier() == c.getIdentifier())action: ALLOW} rule ClientReadTraders {description: "Allow clients to view traders"participant: "org.acme.mynetwork.Client"operation: READresource: "org.acme.mynetwork.Trader"action: ALLOW} rule ClientReadHistorianRecord {description: "Allow clients to view their historian records"participant(c): "org.acme.mynetwork.Client"operation: READresource(hr): "org.hyperledger.composer.system.HistorianRecord"condition: (hr.transactionType == "org.acme.mynetwork.Trade" && hr.transactionInvoked.client.getIdentifier() == c.getIdentifier())action: ALLOW} /* Custodian */ rule CustodianReadAllTrades {description: "Allow custodian to view all trades"participant: "org.acme.mynetwork.Custodian"operation: READresource: "org.acme.mynetwork.Trade"action: ALLOW} rule CustodianReadAllLots {description: "Allow custodian to view all lots"participant: "org.acme.mynetwork.Custodian"operation: READresource: "org.acme.mynetwork.Lot"action: ALLOW} rule CustodianReadAllClients {description: "Allow custodian to view all clients"participant: "org.acme.mynetwork.Custodian"operation: READresource: "org.acme.mynetwork.Client"action: ALLOW} rule CustodianReadAllEvents {description: "Allow custodian to subscribe to NewTrade events"participant: "org.acme.mynetwork.Custodian"operation: READresource: "org.acme.mynetwork.NewTradeEvent"action: ALLOW} rule CustodianReadAllTraders {description: "Allow custodian to view all traders"participant: "org.acme.mynetwork.Custodian"operation: READresource: "org.acme.mynetwork.Trader"action: ALLOW} rule CustodianReadOwnCustodian {description: "Allow custodian to view their info"participant(c): "org.acme.mynetwork.Custodian"operation: READresource(cc): "org.acme.mynetwork.Custodian"condition: (cc.getIdentifier() == c.getIdentifier())action: ALLOW} rule CustodianReadHistorianRecord {description: "Allow custodian to view all trade historian records"participant(t): "org.acme.mynetwork.Custodian"operation: READresource(hr): "org.hyperledger.composer.system.HistorianRecord"condition: (hr.transactionType == "org.acme.mynetwork.Trade")action: ALLOW} After all steps are completed, we can deploy the application by clicking on the left. Update How to test in Playground Now that we have the complete definition of our application, we can test it using the Composer Playground Test module (click at the top). Test 1. Create participants First, let’s seed our application with some participants. We can create 2 clients: a custodian and a trader. 2. Create identities for each participant In order to be able to interact with the business network a participant needs an associated identity. Identities can be created in the ID registry (open the user dropdown on the top right). We’ll create an identity for each participant by specifying its name and pointing to an instance of the participant created in the previous step. At a minimum, we need 4 identities: 2 clients, 1 trader, and 1 custodian. 3. Login as Trader We can now login using the newly created identities by clicking “Use now” next to each identity in the list. First, we login as a trader and create a new Lot that doesn’t belong to any client (client ID is null). Then, we assign the ownership of this lot to client 1 via a Trade transaction. Now, let’s create one more lot and assign it to client 2 via another Trade. 4. Login as Client Then, we’ll login as client 1 and client 2 to check if we can see our Lots. Client 1 lots Client 2 lots As you can see, each client sees only lots that they have ownership of and they are not aware of trades for other clients. 5. Login as Custodian Let’s login as a custodian to check that we can view all trades. Indeed, both trades are visible, as you can see below. Custodian can also view history of all trades: Note on decentralization Keep in mind that when a transaction is broadcasted to the Hyperledger Fabric network, each configured peer is independently executing the custom transaction processing logic which ensures the correctness of the blockchain update. That’s a major architectural difference and — in many cases — an advantage over the traditional centralized, client-server approach. In the traditional approach a single organization would be responsible for managing the data and exposing it to other participants, forcing others to trust it and making it a potential single point of failure. In the blockchain approach, each peer is responsible for managing and reconciling their own copy of the data. This makes the entire network more resilient and decentralized. However, it is not completely simple to configure. There are additional privacy implications to consider since the data is now hosted in many places which creates a potentially larger threat surface. Conclusion Hopefully this has given you a better understanding of what Hyperledger Composer is and how it can be useful in sharing information and keeping track of assets and other concepts among multiple participants. Feel free to export the .bna file of your network and follow the tutorial to deploy the application to a local Hyperledger Fabric network. We’d love to hear your thoughts on Hyperledger Composer. Please, leave any questions or comments below. here

Stories, News & Mentions about MSANETWORK

Msanetwork’s Stories on HackerNoon

Msanetwork's News & Mentions