Meru Data

merudata

Integrating Blockchain in AI Model Training: License Management and Metadata Tracking

COPA v. Wright, Court Filing, retrieved on January 29, 2024, is part of HackerNoon’s Legal PDF Series. You can jump to any part of this filing here. This part is 28 of 42. 26. The SSRN Submission (Particulars of Claim at [30]-[35] {A/2/10}) The Fourth Pleaded Example 489. On or about 21 August 2019, Dr Wright uploaded to the Social Science Research Network (SSRN) a document which he asserts to be the ‘final’ version of the Bitcoin White Paper, in which he is named as the author. The post claims that the document was written on 21 August 2008. Dr Wright posted two versions of what he claims to be his original version of the Bitcoin White Paper within SSRN. **(a) COPA’s Reasons for Alleging Forgery** 490. The metadata of the actual Bitcoin White Paper has a creation date of 24 March 2009. The first version Dr Wright submitted to SSRN has discrepancies in the document properties. Examination of this first version reveals that its metadata was tampered with - supplemental metadata was added to this version to superficially indicate a creation date of 24 January 2008 and a “modified” date of 21 May 2008. This added metadata displays as the creation and modified date in the user interface of standard consumer software, i.e. the tampered dates are what would appear to a layperson upon cursory examination. However, a forensic examination of the metadata of this first version reveals another “creation date” entry embedded within the metadata, specifying a creation date that corresponds exactly to the creation date of the Bitcoin White Paper, specifically “/CreationDate (D:20090324113315-06:00)". 491. The metadata of this first version includes an entry indicating that the original creation date is 29 March 2009, which is at odds with the creation date of 24 January 2008 that shows up in other parts of the metadata. In the premises, it is averred that this first version posted to SSRN is actually a copied version of the Bitcoin White Paper with alterations to its metadata (at least that the dates of 24 January 2008 and 21 May 2008 were added to the genuine metadata of the Bitcoin White Paper) to make it appear that it was created in 2008. It is averred that the dates of 24 January 2008 and 21 May 2008 were added to the genuine metadata of the Bitcoin White Paper by Wright to support his attempt to claim that he had drafted the Bitcoin White Paper. 492. The second version that Dr Wright uploaded to SSRN, which is the version he has currently uploaded there, had further changes to the metadata compared to the first version. However, the original creation date of 24 March 2009 from the actual Bitcoin White Paper still exists within the second version’s metadata. COPA allege that Dr Wright again sought to manipulate the metadata a second time but failed to remove the original creation date. 493. The genuine metadata in the actual Bitcoin White Paper and metadata contained within the two versions posted on SSRN by Dr Wright all state the 24 March 2009 date as being the creation date, with the dates/times agreeing to the millisecond. (b) Dr Wright’s Explanations and COPA’s Rebuttal 494. In his Defence, Dr Wright admits that the two versions of the Bitcoin White Paper which Dr Wright uploaded to SSRN were not created in 2008 or 2009, but in 2019. He claims that his purpose in uploading these versions was not to prove that he was the author of the Bitcoin White Paper but “to assert [his] authorship of the White Paper”: see Defence, [55-56] {A/3/16}. In his Defence, Dr Wright gives no explanation for the uploaded versions having metadata creation dates of 2008 and 2009 respectively. 495. In Appendix B to Wright11, Dr Wright repeats the account given in his Defence. However, he now adds the assertion that he prepared each document in LATEX and that he set the metadata in LATEX to refer to creation dates of 2008 and 2009 respectively. See: {CSW/3/8}. 496. COPA submitted that Dr Wright’s explanation should be rejected for the following reasons: 496.1. As established by the evidence of Mr Rosendahl (which was agreed in the joint statement by Dr Wright’s expert, Mr Lynch), Dr Wright’s account of the Bitcoin White Paper being authored in LATEX is false. There is equally no basis for saying that the versions of the White Paper uploaded to the SSRN in 2019 were created in LATEX. 496.2. Accordingly, the only conclusion to be drawn from these versions having been created by Dr Wright in 2019 (as is admitted) but containing metadata referring to 2008 / 2009 creation dates is that the metadata information was deliberately backdated. 496.3. In summary, Dr Wright in 2019 posted publicly two versions of the Bitcoin White Paper which he presented as his work and which contained metadata timestamps backdated to 2008. In the context of Dr Wright claiming to be Satoshi Nakamoto and to have written the Bitcoin White Paper, the only plausible explanation is that he was presenting these to the world as early originals of the paper written by him. (c) Conclusion 497. In addition to the points set out above, I refer also to the analysis in the main Judgment at [489]-[495] of what Dr Wright did with the pdfcreationdate command and how those commands were added to the White Paper LaTeX files in November 2023. 498. Accordingly, Dr Wright’s latest explanation, based on the assertion that the Bitcoin White Paper was created in LATEX, is plainly false. The document was deliberately backdated by Dr Wright, in an attempt to present those two versions of the Bitcoin White Paper as early originals written by him. This was all lies. Continue Reading Here. About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings.

This court case retrieved on January 29, 2024, judiciary.uk is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. COPA v. Wright, Court Filing, retrieved on January 29, 2024, is part of HackerNoon’s Legal PDF Series. You can jump to any part of this filing here. This part is 28 of 42. COPA v. Wright, Court Filing, retrieved on January 29, 2024, is part of HackerNoon’s Legal PDF Series . You can jump to any part of this filing here . This part is 28 of 42. HackerNoon’s Legal PDF Series HackerNoon’s Legal PDF Series here here 26. The SSRN Submission (Particulars of Claim at [30]-[35] {A/2/10}) The Fourth Pleaded Example 489. On or about 21 August 2019, Dr Wright uploaded to the Social Science Research Network (SSRN) a document which he asserts to be the ‘final’ version of the Bitcoin White Paper, in which he is named as the author. The post claims that the document was written on 21 August 2008. Dr Wright posted two versions of what he claims to be his original version of the Bitcoin White Paper within SSRN. **(a) COPA’s Reasons for Alleging Forgery ** 490. The metadata of the actual Bitcoin White Paper has a creation date of 24 March 2009. The first version Dr Wright submitted to SSRN has discrepancies in the document properties. Examination of this first version reveals that its metadata was tampered with - supplemental metadata was added to this version to superficially indicate a creation date of 24 January 2008 and a “modified” date of 21 May 2008. This added metadata displays as the creation and modified date in the user interface of standard consumer software, i.e. the tampered dates are what would appear to a layperson upon cursory examination. However, a forensic examination of the metadata of this first version reveals another “creation date” entry embedded within the metadata, specifying a creation date that corresponds exactly to the creation date of the Bitcoin White Paper, specifically “/CreationDate (D:20090324113315-06:00)". 491. The metadata of this first version includes an entry indicating that the original creation date is 29 March 2009, which is at odds with the creation date of 24 January 2008 that shows up in other parts of the metadata. In the premises, it is averred that this first version posted to SSRN is actually a copied version of the Bitcoin White Paper with alterations to its metadata (at least that the dates of 24 January 2008 and 21 May 2008 were added to the genuine metadata of the Bitcoin White Paper) to make it appear that it was created in 2008. It is averred that the dates of 24 January 2008 and 21 May 2008 were added to the genuine metadata of the Bitcoin White Paper by Wright to support his attempt to claim that he had drafted the Bitcoin White Paper. 492. The second version that Dr Wright uploaded to SSRN, which is the version he has currently uploaded there, had further changes to the metadata compared to the first version. However, the original creation date of 24 March 2009 from the actual Bitcoin White Paper still exists within the second version’s metadata. COPA allege that Dr Wright again sought to manipulate the metadata a second time but failed to remove the original creation date. 493. The genuine metadata in the actual Bitcoin White Paper and metadata contained within the two versions posted on SSRN by Dr Wright all state the 24 March 2009 date as being the creation date, with the dates/times agreeing to the millisecond. (b) Dr Wright’s Explanations and COPA’s Rebuttal (b) Dr Wright’s Explanations and COPA’s Rebuttal 494. In his Defence, Dr Wright admits that the two versions of the Bitcoin White Paper which Dr Wright uploaded to SSRN were not created in 2008 or 2009, but in 2019. He claims that his purpose in uploading these versions was not to prove that he was the author of the Bitcoin White Paper but “to assert [his] authorship of the White Paper”: see Defence, [55-56] {A/3/16}. In his Defence, Dr Wright gives no explanation for the uploaded versions having metadata creation dates of 2008 and 2009 respectively. 495. In Appendix B to Wright11, Dr Wright repeats the account given in his Defence. However, he now adds the assertion that he prepared each document in LATEX and that he set the metadata in LATEX to refer to creation dates of 2008 and 2009 respectively. See: {CSW/3/8}. 496. COPA submitted that Dr Wright’s explanation should be rejected for the following reasons: 496.1. As established by the evidence of Mr Rosendahl (which was agreed in the joint statement by Dr Wright’s expert, Mr Lynch), Dr Wright’s account of the Bitcoin White Paper being authored in LATEX is false. There is equally no basis for saying that the versions of the White Paper uploaded to the SSRN in 2019 were created in LATEX. 496.2. Accordingly, the only conclusion to be drawn from these versions having been created by Dr Wright in 2019 (as is admitted) but containing metadata referring to 2008 / 2009 creation dates is that the metadata information was deliberately backdated. 496.3. In summary, Dr Wright in 2019 posted publicly two versions of the Bitcoin White Paper which he presented as his work and which contained metadata timestamps backdated to 2008. In the context of Dr Wright claiming to be Satoshi Nakamoto and to have written the Bitcoin White Paper, the only plausible explanation is that he was presenting these to the world as early originals of the paper written by him. (c) Conclusion (c) Conclusion 497. In addition to the points set out above, I refer also to the analysis in the main Judgment at [489]-[495] of what Dr Wright did with the pdfcreationdate command and how those commands were added to the White Paper LaTeX files in November 2023. 498. Accordingly, Dr Wright’s latest explanation, based on the assertion that the Bitcoin White Paper was created in LATEX, is plainly false. The document was deliberately backdated by Dr Wright, in an attempt to present those two versions of the Bitcoin White Paper as early originals written by him. This was all lies. Continue Reading Here. Continue Reading Here . Here About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case retrieved on January 29, 2024, judiciary.uk is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case retrieved on January 29, 2024, judiciary.uk is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. judiciary.uk judiciary.uk

COPA Sues Craig Wright for Forging Bitcoin White Paper Metadata

In the realm of cybersecurity, the phrase "the devil is in the details" rings especially true. One of the most compelling examples of this is the capture of the notorious BTK killer, a serial murderer who eluded law enforcement for decades. His eventual downfall was not due to a dramatic confrontation or an eyewitness tip, but rather through the seemingly mundane details found in metadata. This article explores the critical role of metadata in the BTK case and highlights how tools like Metagoofil can be leveraged in modern cybersecurity efforts. The BTK Killer and the Power of Metadata For more than three decades, the police couldn't manage to arrest the BTK killer. However, authorities finally caught Dennis Rader in 2005 while he was driving near his home in Park City. After the killer's arrest, the nation learned about the heinous crimes he had committed over the years. Dennis Rader, known as the BTK killer (Bind, Torture, Kill), terrorized Wichita, Kansas, from 1974 to 1991, committing a series of brutal murders. For years, he managed to evade capture, taunting law enforcement with letters and clues. His confidence grew, leading him to make a critical error that would ultimately expose him. I will not be talking about the BTK killers’ victims. I will be discussing the methodology used to unmask him. In January 2005, Rader left a package for Wichita’s KAKE-TV inside a cereal box, which he placed in the back of a pickup truck in the parking lot of a local Home Depot store. The owner, however, thought it was garbage and threw it out. Rader then contacted the station, asking if they had received the package. It was later found in the trash, and police were able to review security camera footage that showed a person driving a black Jeep Cherokee dropping off the package. In a subsequent message to police, Rader asked them, “Can I communicate with Floppy [disk] and not be traced to a computer? Be honest.” If so, he told police to place an ad in The Wichita Eagle with the message, “Rex, it will be OK." Two weeks later, a disk arrived in a package sent to KSAS-TV with a file that contained instructions to detectives about further communications. What Rader didn’t realize was the disk also contained encrypted metadata that would lead police straight to him. In 2004, Rader resumed communication with the media and the police, sending a floppy disk to a local news station. He believed that erasing files from the disk would cover his tracks. However, investigators were able to extract metadata from the disk, which included a deleted Microsoft Word document. This document contained metadata revealing it had been last edited by a user named "Dennis" on a computer registered to "Christ Lutheran Church." The disk was handed over to Officer Randy Stone of the Wichita Police Department, who was skilled in computer technology. According to The Wichita Eagle, he used a forensic software program to call up deleted files and other hidden data that showed where and when the disk had been last modified. It revealed the disk had been used on a computer at Wichita’s Christ Lutheran Church by a user named “Dennis.” Upon looking up the church's website, they found "Dennis Rader" listed as the president of the congregation. After locating his home address, police drove by and saw a black Jeep Cherokee in his driveway. After matching Dennis Rader’s DNA to evidence found at several of the crime scenes, police arrested him on February 25, 2005. During his interrogation, Rader expressed his anger at police for lying to him about his floppy disk being traceable. “I need to ask you, how come you lied to me? How come you lied to me?” Rader admonished Lieutenant Ken Landwehr, commander of the Wichita Police Department’s homicide unit. “Because I was trying to catch you,” Landwehr replied. This small piece of information provided a crucial lead. Law enforcement cross-referenced this data with local records, leading them to Dennis Rader, a respected member of the community and church president. DNA evidence subsequently confirmed his identity as the BTK killer, ending his reign of terror. What is Metadata? Metadata means "data about data". Metadata is defined as the data providing information about one or more aspects of the data; it is used to summarize basic information about data that can make tracking and working with specific data easier. Some examples include: the Means of creation of the data.
purpose of the data. What information can be revealed with Metadata? The BTK case underscores the significant role metadata can play in forensic investigations. In the digital age, extracting and analyzing metadata is a cornerstone of cybersecurity. Tools like Metagoofil have become invaluable in this effort. Metagoofil is an open-source tool designed to extract metadata from public documents. By scanning files such as PDFs, Word documents, and images, Metagoofil can reveal hidden information about the document’s creation, modification, and authorship. This can include usernames, software versions, file paths, and other details that can be critical in both offensive and defensive cybersecurity operations. Applications of Metagoofil: Penetration Testing: Cybersecurity professionals can use Metagoofil to gather intelligence about a target organization. By analyzing metadata from publicly available documents, they can identify potential vulnerabilities, software in use, and internal file structures.


Incident Response: During a security breach investigation, Metagoofil can help trace the origin of malicious documents or emails. Metadata can reveal the author’s identity, creation dates, and even geographic locations.


Data Leak Prevention: Organizations can use Metagoofil to audit their own documents before they are released to the public. This helps ensure that sensitive information is not inadvertently shared through metadata.


Compliance and Auditing: Regulatory requirements often mandate the tracking of document handling and modification. Metagoofil can assist in compliance efforts by providing detailed metadata reports. The capture of the BTK killer through metadata analysis serves as a powerful reminder of the hidden value in digital footprints. As cybersecurity threats continue to evolve, the ability to unearth and interpret metadata becomes increasingly vital. Tools like Metagoofil equip professionals with the means to uncover these invisible details, bolstering defenses and enhancing investigative capabilities. In a world where every byte can tell a story, mastering the art of metadata analysis is an essential skill for any cybersecurity arsenal. In the realm of cybersecurity , the phrase "the devil is in the details" rings especially true. One of the most compelling examples of this is the capture of the notorious BTK killer, a serial murderer who eluded law enforcement for decades. His eventual downfall was not due to a dramatic confrontation or an eyewitness tip, but rather through the seemingly mundane details found in metadata. This article explores the critical role of metadata in the BTK case and highlights how tools like Metagoofil can be leveraged in modern cybersecurity efforts. cybersecurity The BTK Killer and the Power of Metadata For more than three decades, the police couldn't manage to arrest the BTK killer. However, authorities finally caught Dennis Rader in 2005 while he was driving near his home in Park City. After the killer's arrest, the nation learned about the heinous crimes he had committed over the years. Dennis Rader, known as the BTK killer (Bind, Torture, Kill), terrorized Wichita, Kansas, from 1974 to 1991, committing a series of brutal murders. For years, he managed to evade capture, taunting law enforcement with letters and clues. His confidence grew, leading him to make a critical error that would ultimately expose him. I will not be talking about the BTK killers’ victims. I will be discussing the methodology used to unmask him. I will not be talking about the BTK killers’ victims. I will be discussing the methodology used to unmask him. In January 2005, Rader left a package for Wichita’s KAKE-TV inside a cereal box, which he placed in the back of a pickup truck in the parking lot of a local Home Depot store. The owner, however, thought it was garbage and threw it out. Rader then contacted the station , asking if they had received the package. It was later found in the trash, and police were able to review security camera footage that showed a person driving a black Jeep Cherokee dropping off the package. In Rader then contacted the station showed a person driving a black Jeep Cherokee In a subsequent message to police, Rader asked them , “Can I communicate with Floppy [disk] and not be traced to a computer? Be honest.” If so, he told police to place an ad in The Wichita Eagle with the message, “Rex, it will be OK." Two weeks later, a disk arrived in a package sent to KSAS-TV with a file that contained instructions to detectives about further communications. What Rader didn’t realize was the disk also contained encrypted metadata that would lead police straight to him. Rader asked them In 2004, Rader resumed communication with the media and the police, sending a floppy disk to a local news station. He believed that erasing files from the disk would cover his tracks. However, investigators were able to extract metadata from the disk, which included a deleted Microsoft Word document. This document contained metadata revealing it had been last edited by a user named "Dennis" on a computer registered to "Christ Lutheran Church." The disk was handed over to Officer Randy Stone of the Wichita Police Department, who was skilled in computer technology. According to The Wichita Eagle , he used a forensic software program to call up deleted files and other hidden data that showed where and when the disk had been last modified. It revealed the disk had been used on a computer at Wichita’s Christ Lutheran Church by a user named “Dennis.” Upon looking up the church's website , they found "Dennis Rader" listed as the president of the congregation. After locating his home address, police drove by and saw a black Jeep Cherokee in his driveway. According to The Wichita Eagle the church's website saw a black Jeep Cherokee After matching Dennis Rader’s DNA to evidence found at several of the crime scenes , police arrested him on February 25, 2005. During his interrogation, Rader expressed his anger at police for lying to him about his floppy disk being traceable. “I need to ask you, how come you lied to me? How come you lied to me?” Rader admonished Lieutenant Ken Landwehr , commander of the Wichita Police Department’s homicide unit. “Because I was trying to catch you,” Landwehr replied. This small piece of information provided a crucial lead. Law enforcement cross-referenced this data with local records, leading them to Dennis Rader, a respected member of the community and church president. DNA evidence subsequently confirmed his identity as the BTK killer, ending his reign of terror. several of the crime scenes arrested him Rader admonished Lieutenant Ken Landwehr What is Metadata? Metadata means " data about data ". Metadata is defined as the data providing information about one or more aspects of the data; it is used to summarize basic information about data that can make tracking and working with specific data easier. data about data Some examples include: the Means of creation of the data. purpose of the data. the Means of creation of the data. purpose of the data. What information can be revealed with Metadata? The BTK case underscores the significant role metadata can play in forensic investigations. In the digital age, extracting and analyzing metadata is a cornerstone of cybersecurity. Tools like Metagoofil have become invaluable in this effort. Metagoofil is an open-source tool designed to extract metadata from public documents. By scanning files such as PDFs, Word documents, and images, Metagoofil can reveal hidden information about the document’s creation, modification, and authorship. This can include usernames, software versions, file paths, and other details that can be critical in both offensive and defensive cybersecurity operations. Applications of Metagoofil: Applications of Metagoofil: Penetration Testing: Cybersecurity professionals can use Metagoofil to gather intelligence about a target organization. By analyzing metadata from publicly available documents, they can identify potential vulnerabilities, software in use, and internal file structures. Incident Response: During a security breach investigation, Metagoofil can help trace the origin of malicious documents or emails. Metadata can reveal the author’s identity, creation dates, and even geographic locations. Data Leak Prevention: Organizations can use Metagoofil to audit their own documents before they are released to the public. This helps ensure that sensitive information is not inadvertently shared through metadata. Compliance and Auditing: Regulatory requirements often mandate the tracking of document handling and modification. Metagoofil can assist in compliance efforts by providing detailed metadata reports. Penetration Testing: Cybersecurity professionals can use Metagoofil to gather intelligence about a target organization. By analyzing metadata from publicly available documents, they can identify potential vulnerabilities, software in use, and internal file structures. Penetration Testing: Cybersecurity professionals can use Metagoofil to gather intelligence about a target organization. By analyzing metadata from publicly available documents, they can identify potential vulnerabilities, software in use, and internal file structures. Penetration Testing: Incident Response: During a security breach investigation, Metagoofil can help trace the origin of malicious documents or emails. Metadata can reveal the author’s identity, creation dates, and even geographic locations. Incident Response: During a security breach investigation, Metagoofil can help trace the origin of malicious documents or emails. Metadata can reveal the author’s identity, creation dates, and even geographic locations. Incident Response: Data Leak Prevention: Organizations can use Metagoofil to audit their own documents before they are released to the public. This helps ensure that sensitive information is not inadvertently shared through metadata. Data Leak Prevention: Organizations can use Metagoofil to audit their own documents before they are released to the public. This helps ensure that sensitive information is not inadvertently shared through metadata. Data Leak Prevention: Compliance and Auditing: Regulatory requirements often mandate the tracking of document handling and modification. Metagoofil can assist in compliance efforts by providing detailed metadata reports. Compliance and Auditing: Regulatory requirements often mandate the tracking of document handling and modification. Metagoofil can assist in compliance efforts by providing detailed metadata reports. Compliance and Auditing: The capture of the BTK killer through metadata analysis serves as a powerful reminder of the hidden value in digital footprints. As cybersecurity threats continue to evolve, the ability to unearth and interpret metadata becomes increasingly vital. Tools like Metagoofil equip professionals with the means to uncover these invisible details, bolstering defenses and enhancing investigative capabilities. In a world where every byte can tell a story, mastering the art of metadata analysis is an essential skill for any cybersecurity arsenal.

Solving Crimes with Data: The BTK Killer and the Power of Metadata Analysis

It is difficult for the metadata in dNFT(dynamic NFT) to achieve “decentralization” and “dynamic change” at the same time. Decentralized metadata storage About (most NFTs are static) metadata is decentralized and stored on IPFS. The format suffix is *,* where refers to the NFT collection, where is a number, such as “26”. An example of such a project is , the metadata of which is stored in IPFS, although the BaseURI used for IPFS can be changed by the contract owner. 48% of NFT ipfs/your_collection_file_hash/tokenid your_collection_file tokenid Bored Ape Yacht Club Suppose the platform wants to provide NFT customization capabilities and put metadata in decentralized storage. In that case, developers need to exhaust all possible combinations of attributes, put all the varieties of metadata on IPFS, and then index according to the combination of attributes to find the in IPFS to get the metadata. tokenURI The disadvantages of this approach are: First, many metadata combinations lead to much storage cost in advance. You have to store them all in advance; Second, if the platform wants to add a Smartglasses option to the feature of Glasses, or when it provides the ability to change dynamically, it can change the metadata information in the NFT about the game level and other metadata information in the NFT according to the goals of the World Cup during a match. At this point, the timeliness requirements for metadata changes are higher. For example, this dynamic change almost equals replacing a new NFT, and the cost of changing NFT metadata will rise sharply. Dynamically update first The second method is to abandon the decentralized metadata storage and only put the ownership on the Chain to ensure timely and rapid dynamic changes. Some projects generate metadata through a centralized server, and the metadata information of the customized NFT will be combined and generated in a centralized manner. To be able to display different houses in 2022 and 2027, NFT minter should first put other roofs on the Chain, store metadata off the Chain, and the URL of a centralized service to do the correlation, pointing to one of them in 2022, and replacing it in 2037 to another one. However, they store metadata on their central storage, and these servers can fail in the blink of an eye, costing NFT owners millions worldwide. More importantly, it isn’t easy to guarantee that such storage will not be tampered with. Especially for some game NFTs, their value does not lie in the displayed pictures but in the information that is crucial in the game, such as force values, levels, etc. This information is stored in metadata. It is impossible to guarantee that only the owner of the NFT owner who can change the metadata based on centralized storage. And when the metadata storage is separated from data on the Chain, the dynamic metadata history does not leave traces on the Chain, and the two are unrelated, so it isn’t easy to carry out practical analysis and insight. Year Transaction price Metadata history 2021 $40,000 old roof; old door 2025 $45,000 old roof; old door 2027 $48,000 old roof—>new roof; old door 2029 $70,000 2031 old door—>new door; new roof 2037 ? The history of the house Currently, only the first two columns of data are kept on-chain, which you can see directly from platforms like OpenSea. But you only know that the price is increasing over time, but you need to understand why. The last data column is in the platform’s centralized server, which is unreliable. For example, a sharp price increase in 2029 is due to the repair of a new roof — the information about this is in the third column of metadata. Because the metadata is changing and is not stored on the Chain, it may be tampered with, so you cannot know, nor is it challenging to analyze and understand what a more reasonable price in 2037 is. These problems may lead to a poor display experience of dNFT in the NFT trading market, making it difficult for dNFT to circulate and prosper in the secondary market. For example, in OpenSea, a dNFT that changes with the daily sunshine conditions rotates the animation every 8 hours, the change history of metadata is not presented on the website, and the dynamic feature is completely invisible when you first enter it. You have no way of knowing this is dynamic. Put all the things on the Chain. Therefore, it is best to put all metadata, images, transaction information, etc., on the Chain and can add the metadata and change it conveniently and dynamically. Your signature should perform the changes, and the NFT platform as an intermediary minimizes the direct touch of data (reading and writing, caching, etc.). DB3 network Here, let me introduce the , a decentralized storage solution that adopts the key-value storage paradigm and has advanced database properties, such as mutation and programmability. DB3 network Change metadata quickly based on decentralized storage. DB3 can support convenient CRUD-like operations, insert, update, read and delete stored data. This is easy to achieve for centralized storage, but it is challenging for decentralized storage. The reason is that the update operation conflicts with the immutable characteristics of the blockchain. But in use cases such as the dynamic NFT mentioned above, immutable storage is important from a security point of view. Still, it limits the number of possible applications (such as the evolutionary ability of NFT). A mutation is defined in the DB3 network as our core concept. All operations on data modification are defined as mutation. You can use mutation to insert, update and delete data. For example, you can easily complete the data renewal when you want to modify roof color metadata. >put house roofcolor offwhite
submit mutation to mempool done!
>get house roofcolor
roof -> offwhite At the same time, mutation can perform data update operations, and the other three: insert/update/delete and the hash returned by these operations will be submitted to the block. the operation is recorded into blocks. Analyze metadata history onchain Every metadata change of dNFT will be recorded on the chain like a snapshot. At the same time, because we have optimized the efficiency of our storage engine, we can achieve high-performance queries, not inferior to the web2 database. Therefore, in the future, analysis of dNFT will be very easy to read and display a more credible metadata history. Claim metadata ownership Secondly, the description information of dNFT will be stored in a concept similar to the “table” in web2. The operation and modification of this table need to obtain the user’s permission, which the user completely controls, ensuring the ownership of dNFT. The centralized service should barely touch metadata. Since the metadata defines the asset, securing metadata is as important as securing ownership. Our ： Github Browse some design docs; Start coding from ; goodfirstissue Discuss with us according the . WIPissue Also published . here

Storing Dynamic NFT Metadata on the DB3 Network

Dear Bankless Nation, Some popular NFT platforms from the 2017-2018 era, like Ascribe, Digital Objects, and Editional, eventually went under. These projects stored their metadata on their own servers, so when they went bust, their tokens’ visuals were lost to time. Lost NFTs are nothing new, then. But these early losses later spurred lots of advances around decentralized storage networks as well as totally on-chain NFTs, whose metadata are forever retrievable from the blockchain. Not everyone pays attention to the lessons of crypto history, though. For example, consider Sam Bankman-Fried of FTX notoriety. This is what his first NFT minted on FTX looked like circa September 2021: No Picasso, right? Certainly not, but at least it had visuals and metadata then. Fast forward to today and in the wake of FTX’s collapse that same NFT, plus all the other NFTs minted at FTX, now have broken metadata: Why? Because SBF and FTX relied on a centralized server system and it’s not running those servers anymore. This system was “good enough” before, but it’s nonexistent now! As such, this episode is the latest big reminder that metadata — whether that be through nodes on decentralized storage networks like Arweave and IPFS or on-chain through Ethereum nodes — is part of the magic of NFTs. decentralizing All that said, . In the meantime let’s catch you up on all the latest headlines in the space, have a great weekend everyone ✌️ backup what NFTs you can when you can -WMP 📣 General NFT News held its third drop ft. Li Jin: Bankless Bankless Collectibles commenced claims for its . Blur second airdrop introduced the : CoinLedger NFT Tax Loss Harvestooor , a new general NFT marketplace, . GigaMart launched introduced the Ledger Stax, a new crypto hardware wallet that’s capable of displaying NFTs: Ledger introduced . Mirror improved NFT embeds added to its community marketplace generator. Rarible Polygon support , a membership rewards program in collaboration with Polygon, . Starbucks Odyssey kicked off , an early-stage web3 fund, . Variant acquired multiple Nouns 🏆 Digital Collectibles launched oracle connectivity, meaning finiliars now respond with emotional animations to their native cryptos’ prices: Finiliar reached a 4Ξ floor for the . Pudgy Penguins first time this year mints and holders stats . Reddit Avatar continue to boom 🎨 Cryptoart selections began, a project he collaborated on with the estate of artist László Moholy-Nagy: Dmitri Cherniak’s Light Years added a , for tracking recent payments and royalties, to Manifold Studio. Manifold Token Activity dashboard , a new marketplace for generative art, has arrived: sansa 🎮 Decentralized Gaming introduced , a new series of expanded gameplay mechanics. Axie Infinity Axie Core , a decentralized esports team, entered into a . BLKHVND partnership with ParagonsDAO introduced code that allows projects to receive royalties from . Pirate Nation both Blur and OpenSea 💽 Music NFTs celebrated its first birthday: Sound 🌐 Virtual Worlds , the parent entity of Aave, acquired mobile with plans to integrate web3 social infra Lens Protocol into the platform. Aave Companies mobiel metaverse Sonar added support for to its marketplace. Decentraland LAND rentals 💎 DeFi x NFTs borrowers can now mint, transfer, or sell their . NFTfi loan obligations , a protocol for collective ownership of NFTs, . Tessera launched Action steps 🆕 Read and in (newsletter) The Status of Web3 Social The Perks of Decentralized Perps Bankless 🗣️ Watch on (YouTube) The Bull Case for Modular Blockchains Bankless 🌱 Watch on Circles UBI with Martin Koppelmann Green Pill 🙇 Catch up on my other write-ups from this week! ✧ NFT TCRs ✧ Collective NFT experiences with Tessera ✧ The Bankless Holiday Crypto Gift Guide Author Bio William M. Peaster is a professional writer and creator of Metaversal —a Bankless newsletter focused on the emergence of NFTs in the crypto economy. He’s also recently been contributing content to Bankless, JPG, and beyond! First Published Here .

Where Has Your NFT Metadata Gone?

The first step you’ll take to building an NFT minting Dapp is to prepare the artwork. Without the artwork, you can’t have your NFT project actualized. Another reason for preprocessing your artworks is for generating metadata for each of the images. Without this metadata, your NFT cannot be sold in any of the big secondary markets, such as Opensea. For example, the image below is an NFT in the Opensea marketplace bearing some metadata which can also be seen below. The above information including the artwork, its details, and traits can be seen on the IPFS image below. Setting up Project Dependencies Open your terminal and navigate to your project directory or create a project folder at a specific location. For example, running on the terminal will create a folder called “ on your specified location. **mkdir preprocessor** preprocessor” Next, run the following commands on the terminal. cd preprocessor
npm init -y
npm install sharp @faker.js/faker --save-dev The above commands will install both and libraries on your project. The faker library will help us generate random information. Whereas, the sharp library will help us process the image to a certain dimension, quality, and format. sharp faker Next, create a folder in your project called and another called . In the “arts” folder, put all the images for processing inside it. arts outputs With the above steps accomplished, open the project on “VS code”. The project structure should look like the one below. - preprocessor/
  - arts/
  - node_modules/
  - outputs/
  - package.json
  - package-lock.json Great, let’s move on to coding the engine responsible for processing the images. Prerequisites You’ll need the following installed on your computer to complete this tutorial. NodeJs IPFS Desktop app VS Code Coding the Processing Engine Create a file at the root of your project called and paste the following code **imagify.js** const fs = require('fs')
const path = require('path')
const sharp = require('sharp')
const { faker } = require('@faker-js/faker')
const input = './arts'
const output = './outputs'

let img_counter = 1
const imgSize = { width: 500, height: 500 }
const desired_ext = '.webp'
const base_url = 'https://ipfs.io/ipfs/REPLACE_WITH_IPFS_CID/'
const attributes = {
  weapon: [
    'Stick',
    'Knife',
    'Blade',
    'Clube',
    'Ax',
    'Sword',
    'Spear',
    'Gun',
    'Craft',
  ],
  environment: [
    'Space',
    'Sky',
    'Desert',
    'Forest',
    'Grassland',
    'Moiuntains',
    'Oceans',
    'Rainforest',
  ],
  rarity: Array.from(Array(10).keys()),
}

fs.readdirSync(input).forEach((file) => {
  const orginal_ext = path.extname(file)
  const orginal_file_name = path.basename(file).split('.')[0]

  if (['.jpg', '.jpeg', '.png', '.gif', '.webp'].includes(orginal_ext)) {
    const id = img_counter

    const metadata = {
      id,
      name: `Adulam NFT #${id}`,
      description:
        'A.I Arts NFTs Collection, Mint and collect the hottest NFTs around.',
      price: 1,
      image: base_url + id + desired_ext,
      demand: faker.random.numeric({ min: 10, max: 100 }),
      attributes: [
        {
          trait_type: 'Environment',
          value: attributes.environment.sort(() => 0.5 - Math.random())[0],
        },
        {
          trait_type: 'Weapon',
          value: attributes.weapon.sort(() => 0.5 - Math.random())[0],
        },
        {
          trait_type: 'Rarity',
          value: attributes.rarity.sort(() => 0.5 - Math.random())[0],
          max_value: 10,
        },
        {
          display_type: 'date',
          trait_type: 'Created',
          value: Date.now(),
        },
        {
          display_type: 'number',
          trait_type: 'generation',
          value: 1,
        },
      ],
    }

    if (fs.existsSync(`${input}/${orginal_file_name + orginal_ext}`)) {
      sharp(`${input}/${orginal_file_name + orginal_ext}`)
        .resize(imgSize.height, imgSize.width)
        .toFile(`${output}/images/${id + desired_ext}`, (err, info) =>
          console.log(err),
        )

      fs.writeFileSync(`${output}/metadata/${id}.json`, JSON.stringify(metadata), {
        encoding: 'utf-8',
        flag: 'w',
      })
    }
    console.log(metadata)
    img_counter++
  }
}) The following steps will help you understand how this metadata processing engine works. Importing Essential Libraries const fs = require('fs')
const path = require('path')
const sharp = require('sharp')
const { faker } = require('@faker-js/faker')
const input = './arts'
const output = './outputs' The represents the file system, it is an inbuilt module that came with NodeJs. It has the responsibility of managing file reading and writing activities on your machine. fs The is another node module that helps you navigate through the directory structures on your machine. This will be instrumental in locating where our images are kept. path Sharp is the module we use for processing the image such as resizing and transforming to a different file type. We’ll use the faker to generate a random number. Lastly, the variable contains the location where the images to be processed are located and the points to the location where the processed images will be saved. input output Defining Essential Variables let img_counter = 1
const imgSize = { width: 500, height: 500 }
const desired_ext = '.webp'
const base_url = 'https://ipfs.io/ipfs/REPLACE_WITH_IPFS_CID/'
const attributes = {
  weapon: [
    'Stick',
    'Knife',
    'Blade',
    'Clube',
    'Ax',
    'Sword',
    'Spear',
    'Gun',
    'Craft',
  ],
  environment: [
    'Space',
    'Sky',
    'Desert',
    'Forest',
    'Grassland',
    'Moiuntains',
    'Oceans',
    'Rainforest',
  ],
  rarity: Array.from(Array(10).keys()),
} The above codes contain important variables to be used in the course of generating our metadata. helps us to number the images consistently with the current iteration. **Image_counter** defines the dimension of the width and height of each image to be processed. **ImgSize** speaks of the file format you want your processed images to bear. **Desired_ext** specifies the location where the images are to be stored on the IPFS. **Base_url** holds further information about each image’s metadata. **Attributes** Executing Recursive Task fs.readdirSync(input).forEach((file) => {
  if(['.jpg', '.jpeg', '.png', '.gif', '.webp'].includes(orginal_ext)) {
    // Images and metadata tasks are recursively performed here...
  }
}) In the above block of code, we used the file system library (fs) to loop through all the images in the location (arts). And for each of the images, we made sure our engine is only selecting images from an approved list of extensions. **input** Performing The Metadata Task const id = img_counter
const metadata = {
  id,
  name: `Adulam NFT #${id}`,
  description:
    'A.I Arts NFTs Collection, Mint and collect the hottest NFTs around.',
  price: 1,
  image: base_url + id + desired_ext,
  demand: faker.random.numeric({ min: 10, max: 100 }),
  attributes: [
    {
      trait_type: 'Environment',
      value: attributes.environment.sort(() => 0.5 - Math.random())[0],
    },
    {
      trait_type: 'Weapon',
      value: attributes.weapon.sort(() => 0.5 - Math.random())[0],
    },
    {
      trait_type: 'Rarity',
      value: attributes.rarity.sort(() => 0.5 - Math.random())[0],
      max_value: 10,
    },
    {
      display_type: 'date',
      trait_type: 'Created',
      value: Date.now(),
    },
    {
      display_type: 'number',
      trait_type: 'generation',
      value: 1,
    },
  ],
} In the code block above, we supplied values for each metadata space. For example, environments, weapons, and all the trait values are randomly and dynamically supplied. Performing The Image Transformation Task if (fs.existsSync(`${input}/${orginal_file_name + orginal_ext}`)) {
  sharp(`${input}/${orginal_file_name + orginal_ext}`)
    .resize(imgSize.height, imgSize.width)
    .toFile(`${output}/images/${id + desired_ext}`, (err, info) =>
      console.log(err),
    )

  fs.writeFileSync(`${output}/metadata/${id}.json`, JSON.stringify(metadata), {
    encoding: 'utf-8',
    flag: 'w',
  })
}

console.log(metadata)
img_counter++ In the snippet above, we used the file system module again to first locate each one of our artwork and resized it to our specified dimension (500 x 500). Also, we supplied a new name in line with the current iteration and gave it our desired extension (webp). Resizing and transforming the images into greatly optimized our artworks to an astonishing height. webp For example, where I subjected this image preprocessing engine to images totaling a size of . The size went down to for the extension and an astonishing for the extension. That huge size reduction accounts for a big leap in the load time of a Minting website built with my images. in this video 99 111MB 62MB .png 4.5MB .webp Lastly from the block of code above, we created metadata for each image processed, bearing both an identical name and a URL pointing to the image’s location. This metadata is what we’ll deploy to IPFS after processing the images. JSON Now, run the command below to have your image transformed. Be sure you are in your project folder. node imagify.js At this point, we are done with our image engine, our output folder should have the following file structure as the result. - output/
  - images
    - 1.webp
    - 2.webp
    - ......
  - metadata
    - 1.json
    - 2.json
    - ...... Uploading Images and Metadata to IPFS IPFS stands for the interplanetary file system, it is peer-to-peer and decentralized. There isn’t an easy way to pull out data stored on the IPFS and as such, it is a near-perfect peer to use along with your blockchain applications for storing media contents. To use the easy and less confusing way, head to the IPFS Desktop app installation page and follow the instructions specified there. After the installation is successful, open up the IPFS app and upload FIRST, and I repeat, FIRST upload the images folder. A unique CID (content Identification) string will be generated as part of the folder name, see the image below. Now, copy the images folder CID as can be seen from the image above, and replace it in your code. See the code below. **imagify.js** const base_url = "https://ipfs.io/ipfs/REPLACE_WITH_IPFS_CID/" //old string
const base_url = "https://ipfs.io/ipfs/QmY1zrFibpdHQ7qcqZqq7THsqTremZYepXNWR5Au3MF1ST/" //new string Now, run the again to include the accurate location of each image to your metadata. See an example of the generated JSON metadata before and after the replacement of the CID. **node imagify.js** JSON You can watch this video to understand how I used these Images and metadata on a full NFT minting Project. https://www.youtube.com/watch?v=QN3wb_mXBjY?embedable=true Before CID Replacement {
  id: 97,
  name: 'Adulam NFT #97',
  description: 'A.I Arts NFTs Collection, Mint and collect the hottest NFTs around.',
  price: 1,
  image: 'https://ipfs.io/ipfs/REPLACE_WITH_IPFS_CID/97.webp',
  demand: '4',
  attributes: [
    { trait_type: 'Environment', value: 'Forest' },
    { trait_type: 'Weapon', value: 'Craft' },
    { trait_type: 'Rarity', value: 4, max_value: 10 },
    {
      display_type: 'date',
      trait_type: 'Created',
      value: 1664478034024
    },
    { display_type: 'number', trait_type: 'generation', value: 1 }
  ]
} After CID Replacement {
  id: 97,
  name: 'Adulam NFT #97',
  description: 'A.I Arts NFTs Collection, Mint and collect the hottest NFTs around.',
  price: 1,
  image: 'https://ipfs.io/ipfs/QmY1zrFibpdHQ7qcqZqq7THsqTremZYepXNWR5Au3MF1ST/97.webp',
  demand: '7',
  attributes: [
    { trait_type: 'Environment', value: 'Moiuntains' },
    { trait_type: 'Weapon', value: 'Clube' },
    { trait_type: 'Rarity', value: 2, max_value: 10 },
    {
      display_type: 'date',
      trait_type: 'Created',
      value: 1664478110287
    },
    { display_type: 'number', trait_type: 'generation', value: 1 }
  ]
} Finally, as shown in the image below, upload the metadata folder to IPFS alongside the images folder. Fantastic, now let’s pin it on the web for the world to see. Currently, both folders are sitting on your local IPFS node (Your Computer), for it to be accessible worldwide, you need to use a Pinning service such as . Pinata Pinning your folders to IPFS First, head to and sign up if you haven’t done that before. Then click on the account icon and select API Keys. See the image below. Pinata pin manager On the keys creation page, click on create a new key and enter the name for the key. Observe the image below. Now copy the JWT key on your clipboard. This is what we’ll use to link our IPFS Desktop with our Pinata account. See the image below. Next, open up your IPFS desktop application, head to the settings tab and add a new service, select Pinata and paste your JWT token to the space provided. Refer to the image below. The last thing to do is to actually pin your folders to Pinata using the instruction below. Head to the files tab, click on the triple dotted line, and select set pinning. This will pop up in the image below. Select Pinata and apply, by so doing, your images folder will be accessible globally. Confirming Global Image Accessibility Head to this website, copy and paste your CID on the IPFS input field and click on the cache button. This scans the entire set of publicly available IPFS gateways in search of your images. See the image below. The results from the above image show that many IPFS nodes now have copies of the images folder available and accessible globally even if you deleted the original copy on your local node. With the steps clearly outlined for you, also Pin the metadata folder to make them publicly available online. Now you can use any of the links in the image above as your base URL for tokens. See the image below. ERC721 And there you have it, that is how to prepare and upload your artworks on the IPFS. Conclusion You will always encounter the need to understand how to preprocess and upload artworks on the IPFS at a batch scale. Once you understand how to work and process images to the IPFS you can start using it on your special web3 projects. Till next time, keep crushing it! See live demo usage on my NFT project on the Goerli testnet . See Opensea’s location . You can watch the video version on my YouTube Channel. here here https://www.youtube.com/watch?v=YzurgMLwFVQ?embedable=true About the Author I am a full-stack blockchain developer with years of experience in the software development industry. 6+ By combining Software Development, writing, and teaching, I demonstrate how to build decentralized applications on EVM-compatible blockchain networks. My stacks include , , , , , , , , and more. JavaScript React Vue Angular Node React Native NextJs Solidity to learn how to build a Web3 app from scratch. I also offer private and specialized classes for serious folks who want to learn one-on-one from a mentor. Subscribe to my YouTube channel . Book your Web3 classes here Now, let me show you how to represent the above image and metadata in your code.

How to Richly Preprocess your IPFS NFT Images and Metadata

Cómo preprocesar enriquecidamente sus imágenes y metadatos IPFS NFT

Comment prétraiter de manière riche vos images et métadonnées IPFS NFT

अपने आईपीएफएस एनएफटी छवियों और मेटाडेटा को बड़े पैमाने पर प्रीप्रोसेस कैसे करें

IPFS NFT 画像とメタデータを豊富に前処理する方法

Como pré-processar ricamente suas imagens e metadados IPFS NFT

Cách tiền xử lý phong phú Hình ảnh và Siêu dữ liệu IPFS NFT của bạn

如何丰富地预处理您的 IPFS NFT 图像和元数据

So far in this blog series, we've created our first live streaming channel, learned how to create a playback experience in the browser, and enhanced that experience with the Amazon Interactive Video Service (Amazon IVS) player SDK. In the next few posts, we're going to look at adding some interactivity to our playback experience. Live streaming is clearly popular, but it's more than just the video that appeals to viewers. Interacting with the broadcaster and other viewers is a major reason so many people keep coming back to certain streams and streamers. Amazon IVS gives us a few pretty amazing features that enable interactivity, and one of the cooler elements that we can use to enhance our live stream is (obligatory " "). timed metadata official doc link Timed Metadata? Timed metadata is a way to embed information in your live stream at a specific point in time. The metadata that you publish becomes a part of the video stream itself since it uses ID3 tags embedded directly into the video segments. That means they are available in later on if we record our live streams. ID3 tags? Ever wonder how your music player knows the artist, song title, album and more about the song it’s playing? Audio files contain a small chunk of data that contains this information. Audio players read this data and display it! What Is It Good For? All kinds of stuff! Using timed metadata, we can create an interactive experience for our viewers outside of the video player. Imagine a game show live stream that can render questions in the browser when the host asks them. Think about a live shopping experience that updates the page with product images, reviews, pricing information, or discount codes as the presenter is demoing the product. What about updating leaderboards, box scores, detailed stats during a live streamed sporting (or e-sports) event? Picture a live streamed bike race that broadcasts the rider’s GPS location with the stream and display it in real time on a map. There are so many use cases, and I’m sure you’ve already thought of a few for your own applications. Enough talk, let’s build something! Listening For Timed Metadata Let's head back once again to the Amazon IVS page. Notice that there is a test stream listed here that contains timed metadata. Nice! We'll plug this into our Amazon IVS player example that we've been working with and build upon it. Here's how that looks: test streams <video id="video-player" controls autoplay playsinline></video> const videoEl = document.getElementById('video-player');
const streamUrl = 'https://fcc3ddae59ed.us-west-2.playback.live-video.net/api/video/v1/us-west-2.893648527354.channel.xhP3ExfcX8ON.m3u8';
const ivsPlayer = IVSPlayer.create();
ivsPlayer.attachHTMLVideoElement(videoEl);
ivsPlayer.load(streamUrl);
ivsPlayer.play(); This stream is an example of a “live trivia” stream where the host reads a few trivia questions. A timed metadata event is embedded at the exact point in time that the host reads a trivia question. We can listen for, and respond to this event. If you remember from our last post, we can use on the Amazon IVS player to listen for various events, and ( ) is one of those events. addEventListener() TEXT_METADATA_CUE docs ivsPlayer.addEventListener(IVSPlayer.PlayerEventType.TEXT_METADATA_CUE, (e) => {
    console.log(e);
}); If we play our stream, we can check the console after the host reads a question and observe the logged event. It should look similar to this: {
    "startTime": 61.04233333333333,
    "endTime": 61.04233333333333,
    "type": "TextMetadataCue",
    "description": "",
    "text": "{\"question\": \"From what language does the term R.S.V.P. originate from?\",\"answers\": [ \"Russian\", \"Italian\", \"French\", \"Portuguese\" ],\"correctIndex\": 2}",
    "owner": "metadata.live-video.net"
} The key represents the time since the stream started the event took place (61 seconds in the example above). The interesting bit we're after here is the key, which contains the metadata. Here, it's a JSON string, but it can be whatever you need it to be. startTime text The only limitation on timed metadata is that the payload must be less than 1kb. That might sound small, but metadata isn't intended to deliver large payloads. We can perform additional steps on the client side if necessary. For example, we could pass a question ID in the example above instead of passing the question, answers, and correct answer and fetch the rest of the information from client memory or a remote API call. But since we've got the entire trivia payload, let's parse the metadata. const metadata = JSON.parse(e.text); The parsed metadata structure uses the following structure: {
    "question": "From what language does the term R.S.V.P. originate from?",
    "answers": [
        "Russian",
        "Italian",
        "French",
        "Portuguese"
    ],
    "correctIndex": 2
} Rendering the Question and Answers So we've got the questions, answers, and the index of the correct answer. Certainly our viewers would be really honest and never poke around in the browser's developer tools to view the correct answer, so we'll proceed with our trivia app on the honor system. Let's render the question and answers. First, we'll add some HTML markup (styled with Bootstrap) below the video player. <div class="card mt-3">

    <div class="card-header bg-dark text-white">
        <h4>Question</h4>
    </div>

    <div class="card-body">

        <div class="card-title">
            <h4 id="question"></h4>
        </div>

        <div id="answerContainer">
            <ul id="answers" class="list-group"></ul>
        </div>

    </div>

    <div class="card-footer text-center">
        <button class="btn btn-dark" id="check-answer-btn" disabled>Submit</button>
    </div>

</div> So we've got a container for our question, and the answers. We've also added a button to check the answer that is initially . Let's add some code inside of our event handler to store the correct answer in the global scope so that we can check the user's answer later on. disabled window.correctIndex = metadata.correctIndex; Now we can enable the submit button, display the question, and clear out the answer container. // enable the submit button
document.getElementById('check-answer-btn').removeAttribute('disabled');

// display the question
document.getElementById('question').innerHTML = metadata.question;

// clear previous answers
const answersEl = document.getElementById('answers');
answersEl.replaceChildren(); Now we can loop over all the answers in the metadata object and render them to the page. // render the answers for this question
metadata.answers.forEach((a, i) => {
    // create an answer container
    const answerEl = document.createElement('li');
    answerEl.classList.add('list-group-item');

    // radio button to select the answer
    const answerRadio = document.createElement('input');
    answerRadio.setAttribute('name', 'answer-input');
    answerRadio.type = 'radio';
    answerRadio.id = `answer-input-${i}`;
    answerRadio.classList.add('me-2', 'form-check-input');
    answerRadio.dataset.index = i;
    answerEl.appendChild(answerRadio);

    // label to display the answer text
    const answerLbl = document.createElement('label');
    answerLbl.setAttribute('for', `answer-input-${i}`);
    answerLbl.innerHTML = a;
    answerEl.appendChild(answerLbl);

    answersEl.appendChild(answerEl);
}); Checking for the Correct Answer Now our application will display the question and answers on the page. We'll need a function that can check whether the user's answer is correct that will provide user feedback, so let's create that now. const checkAnswer = () => {
    // disable the submit btn
    document.getElementById('check-answer-btn').setAttribute('disabled', 'disabled');

    // check the current answer
    const selectedAnswer = document.querySelector('input[name="answer-input"]:checked');
    const selectedIdx = parseInt(selectedAnswer.dataset.index);

    // highlight the correct answer
    document.querySelector(`input[data-index="${window.correctIndex}"]`).nextSibling.classList.add('text-success');

    // if they're wrong, highlight the incorrect answer
    if (selectedIdx !== window.correctIndex) {
        selectedAnswer.nextSibling.classList.add('text-danger');
    }
} Don't forget to attach an event listener for the event on our button. We'll add that in our function. click Submit init() document.getElementById('check-answer-btn').addEventListener('click', checkAnswer); And we're ready to see it in action! If you're playing along at home, check your code against the code in the demo below. If not, check it out anyway to see the final solution. Give it a shot and see how many questions you can get right! Note, you may have to scroll down in the demo to see the question. Producing Timed Metadata We've looked at how to consume metadata, but we've not yet seen how to produce it. No worries - it's not that hard to do! There are several ways to produce timed metadata, and all of them require the . You can get this value from the Amazon IVS Management Console in the channel details, or via the AWS CLI. Channel ARN $ aws \
    ivs \
    list-channels \
    --filter-by-name [YOUR CHANNEL NAME] \
    --query "channels[0].arn" \
    --output text Check out the . Need to Install the CLI? install guide With the AWS CLI One way to produce timed metadata is to use the AWS CLI. I don't know if this is a method that you'd use very often, but for testing and debugging purposes, it's good to know how to do it. $ aws \
    ivs \
    put-metadata \
    --channel-arn [YOUR CHANNEL ARN] \
    --metadata '{"test": true}' . AWS CLI Docs With the Amazon IVS SDK Node SDK import AWS from 'aws-sdk';
const Ivs = new AWS.IVS({ region: 'us-east-1', credentials });

const putMetadata = async (metadata) => {
    const input = {
        channelArn: '[YOUR CHANNEL ARN]',
        metadata: JSON.stringify(metadata)
    };
    let output;
    try {
        output = await Ivs.putMetadata(input).promise();
    }
    catch (e) {
        console.error(e);
        if (e.name === 'ChannelNotBroadcasting') {
            output = { offline: true };
        }
        else {
            throw new Error(e);
        }
    }
    return output;
} . Node SDK docs Python SDK import boto3
client = boto3.client('ivs')

response = client.put_metadata(
    channelArn='[YOUR CHANNEL ARN]',
    metadata='{"python": true}'
)
print(response) . Python SDK Docs Other Languages Check the for the syntax to publish metadata events in your favorite language. SDK specific documentation Summary Timed metadata is infinitely cool and has many applications to make our live stream engaging and interactive. In our next post, we’re going to look at another way we can add interactivity to our live streams - Amazon IVS Chat! Also Published Here

Using Amazon IVS to Create Interactive Live Streaming Experiences with Timed Metadata

Uso de Amazon IVS para crear experiencias interactivas de transmisión en vivo con metadatos cronometrados

With the use of blockchain explorer or by retrieving it from the smart contracts that manage them, you may locate the metadata for your NFTs. is data that provides information about other data; in the case of an NFT, it describes that NFT's essential properties, including its name, description, and anything else its creator feels is important. In many cases, an NFT's metadata also contains links to the images and other "primary" digital assets that give an NFT its value. Metadata (opens new window) Individually identifiable digital representations of blockchain-based tangible or intangible objects called are not typically divided into smaller parts. Instead, structured metadata related to actual or virtual things is represented by NFTs. Often, the tokens are not connected to the objects and serve as distinct identifiers, advancing the interoperable commercialization of the physical or digital items, according to their proponents. nonfungible tokens (NFTs) Hashes of files or other data were added to in 2012 or 2013 to demonstrate their existence or legitimacy at a particular moment. This development served as the foundation for creating "Colored Coins," uniquely identified tokens, which are recognized by adding metadata to Bitcoin transactions. the Bitcoin blockchain What is Metadata? So, what is this metadata, and how is it generated? In this article, we will explore these questions and also deep dive into how you can retrieve metadata of the NFT from the contract; how you read NFT files; and how you can view the metadata of any NFT. What exactly is the location of NFTs that are stored off-chain? Is it anything like Amazon Web Services or Google Drive? This is a crucial point that causes confusion surrounding NFT information. Who else is in charge of the NFT metadata storage online? Since NFT marketplaces use metadata to show nonfungible tokens to buyers and sellers, metadata must be in a format that marketplaces can understand. In other words, you're writing computer code—a smart contract—that instructs the blockchain to initialise a table on your behalf. Your NFTs' ownership and metadata are kept in this table. More particular, each table row has the following details: The Token Identifier (or ID) The Owner of the Token The Metadata associated with the token How can you view the metadata of any NFT? When an NFT project is made available for the minting and you buy it, a random number generator will give your NFT a set of characteristics. The metadata contains this information. The blockchain contains an immutable record of the token's info. This record contains information about the token's purpose, present owner, and previous transactional activity. Consequently, how can you create NFT metadata? Viewing an NFT's metadata, confirming its ownership and tracing its transaction history are all possible using an NFT tracking and verification service through which you can verify that the token ID and contract address are connected to the legitimate owner of the content using a marketplace database. If you select a service that complies with NFT's coding standard, one of the many NFT verification tools available can search for you. An Ethereum blockchain explorer called is a well-known tool for locating and confirming NFTs. The platform allows users to verify transaction histories, wallet addresses, metadata, smart contracts and other on-chain data. Similarly, you can access all the NFT metadata you require on the BNB Chain network by using a blockchain explorer like BscScan. Etherscan However, to retrieve the metadata of a nonfungible token from the smart contracts that control it, you'll need to access the NFT's smart contract. The metadata should be accessible for inspection and verification under the contract's "Details" section. If the NFT complies with the current nonfungible token standard, the following details ought to be shown: Here is a JSON metadata file for a sample NFT. ash-nft.json{ "description": "Friendly OpenSea Creature", "image": "https://opensea-prod.appspot.com/puffs/3.png", "name": "Dave Starbelly", "attributes": [ { "trait_type": "Base", "value": "Starfish" }, { "trait_type": "Eyes", "value": "Big" }, { "trait_type": "Mouth","value": "Surprised" }, ] } The second essential component of NFTs that lets them work is NFT metadata. NFTs have the ability to link to data outside of their smart contract, effectively enabling the network to refer to off-chain data. As a result, executing NFTs on a network like expenses than it otherwise would. Ethereum has lower computing The asset itself often resides off-chain, whereas the Non-Fungible Token that defines the provenance of an asset resides on the blockchain. There are a few exceptions; one is the collection OnChain Monkeys, which was totally built on chain in a single transaction. Since the complete collection is hosted on-chain, no file storage solution is required.

Easy Way to Find Your NFT’s Metadata

Running Cisco pyATS on Windows 11 Really Helped Me Brush Up My Python Fundamentals

SYDNEY, Australia, November 21st, 2024/Chainwire/--The GMT DAO, an independent community organization of GMT holders, is excited to announce the launch of the GMT Burn Initiative—an event designed to place the future of GMT firmly in the hands of its community. Through this initiative, GMT holders will vote on the decision to burn up to 600 million GMT, equivalent to 100 million USD, marking this as one of the most ambitious token burns in the web3 ecosystem. The GMT Burn Initiative reflects the GMT DAO’s commitment to transparency, governance, and sustainable token management. This community-driven approach aligns with the DAO's goal to shape GMT’s future responsibly and collaboratively. How It Works: Lock and Vote: GMT holders can participate by visiting burngmt.com, where they can lock their tokens and cast their vote on various proposals, including the first of its kind “GMT Burn Initiative”. Participants will receive an exclusive soulbound ‘Make GMT Great Again’ Red Hat NFT as a token of acknowledgement for their involvement. This NFT will record metadata detailing the claimed and eligible airdrops, as well as the votes cast.
Earn Rewards: A total of 100 million GMT will be distributed at the end of the 60-day voting period as rewards to participants, contingent on achieving milestones.
On-Chain Transparency: The voting process is recorded on the blockchain, allowing anyone to verify results and ensuring the integrity and transparency of each decision.
Regular Voting Cycles: This burn initiative is just the beginning. Moving forward, GMT DAO will introduce new proposals and voting cycles every quarter, giving holders regular opportunities to shape the future of GMT via gmtdao.com. This initiative showcases a proactive effort to ensure GMT's sustainable future, emphasizing innovation and community engagement. The GMT DAO remains committed to true decentralization, empowering GMT holders to shape its direction. By enabling votes on key proposals, including a potential major token burn, the DAO highlights the power of collective input and its dedication to building a strong, thriving ecosystem. The GMT Burn Initiative marks a new chapter in GMT’s journey, giving every holder a voice. Voting, which starts at 100 GMT, is now open at burngmt.com, inviting all GMT holders to help shape the token's future. About GMT DAO The GMT DAO is an independent organization of GMT holders dedicated to overseeing GMT’s future through transparent and community-led governance. The DAO’s formation represents a commitment to empowering GMT holders with a voice in key decisions, from token management to ecosystem development. For more information on the GMT Burn Initiative and to participate, users can visit burngmt.com. About GMT GMT sits at the heart of the FSL ecosystem. Exclusively earned through STEPN, this token plays a crucial role across all FSL products. GMT operates on four blockchains—Solana, BNB Chain, Ethereum, and Polygon—and is pivotal in Gas Hero, where it's used to trade items and burn for NFT level-ups. On MOOAR, all items can be traded using GMT, and it’s also central to primary sale raffle mints with key partners and is used in the newly launched STEPN GO to buy Sneakers and perform various in app functions. Contact GMT DAO hello@gmtdao.com This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here SYDNEY, Australia, November 21st, 2024/Chainwire/--The GMT DAO, an independent community organization of GMT holders, is excited to announce the launch of the GMT Burn Initiative—an event designed to place the future of GMT firmly in the hands of its community. Through this initiative, GMT holders will vote on the decision to burn up to 600 million GMT, equivalent to 100 million USD, marking this as one of the most ambitious token burns in the web3 ecosystem. The GMT Burn Initiative reflects the GMT DAO’s commitment to transparency, governance, and sustainable token management. This community-driven approach aligns with the DAO's goal to shape GMT’s future responsibly and collaboratively. How It Works: Lock and Vote: GMT holders can participate by visiting burngmt.com, where they can lock their tokens and cast their vote on various proposals, including the first of its kind “GMT Burn Initiative”. Participants will receive an exclusive soulbound ‘Make GMT Great Again’ Red Hat NFT as a token of acknowledgement for their involvement. This NFT will record metadata detailing the claimed and eligible airdrops, as well as the votes cast. Earn Rewards: A total of 100 million GMT will be distributed at the end of the 60-day voting period as rewards to participants, contingent on achieving milestones. On-Chain Transparency: The voting process is recorded on the blockchain, allowing anyone to verify results and ensuring the integrity and transparency of each decision. Regular Voting Cycles: This burn initiative is just the beginning. Moving forward, GMT DAO will introduce new proposals and voting cycles every quarter, giving holders regular opportunities to shape the future of GMT via gmtdao.com. Lock and Vote: GMT holders can participate by visiting burngmt.com , where they can lock their tokens and cast their vote on various proposals, including the first of its kind “GMT Burn Initiative”. Participants will receive an exclusive soulbound ‘Make GMT Great Again’ Red Hat NFT as a token of acknowledgement for their involvement. This NFT will record metadata detailing the claimed and eligible airdrops, as well as the votes cast. burngmt.com burngmt.com Earn Rewards: A total of 100 million GMT will be distributed at the end of the 60-day voting period as rewards to participants, contingent on achieving milestones. On-Chain Transparency: The voting process is recorded on the blockchain, allowing anyone to verify results and ensuring the integrity and transparency of each decision. Regular Voting Cycles: This burn initiative is just the beginning. Moving forward, GMT DAO will introduce new proposals and voting cycles every quarter, giving holders regular opportunities to shape the future of GMT via gmtdao.com . gmtdao.com gmtdao.com This initiative showcases a proactive effort to ensure GMT's sustainable future, emphasizing innovation and community engagement. The GMT DAO remains committed to true decentralization, empowering GMT holders to shape its direction. By enabling votes on key proposals, including a potential major token burn, the DAO highlights the power of collective input and its dedication to building a strong, thriving ecosystem. The GMT Burn Initiative marks a new chapter in GMT’s journey, giving every holder a voice. Voting, which starts at 100 GMT, is now open at burngmt.com , inviting all GMT holders to help shape the token's future. burngmt.com burngmt.com About GMT DAO The GMT DAO is an independent organization of GMT holders dedicated to overseeing GMT’s future through transparent and community-led governance. The DAO’s formation represents a commitment to empowering GMT holders with a voice in key decisions, from token management to ecosystem development. For more information on the GMT Burn Initiative and to participate, users can visit burngmt.com . burngmt.com burngmt.com About GMT GMT sits at the heart of the FSL ecosystem. Exclusively earned through STEPN , this token plays a crucial role across all FSL products. STEPN STEPN GMT operates on four blockchains—Solana, BNB Chain, Ethereum, and Polygon—and is pivotal in Gas Hero , where it's used to trade items and burn for NFT level-ups. Gas Hero Gas Hero On MOOAR , all items can be traded using GMT, and it’s also central to primary sale raffle mints with key partners and is used in the newly launched STEPN GO to buy Sneakers and perform various in app functions. MOOAR MOOAR STEPN GO STEPN GO Contact GMT DAO hello@gmtdao.com This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here here here

GMT DAO Launches Groundbreaking Burn Initiative With a Target Of Up To 600 Million GMT

GMT DAO стартира новаторска инициатива за изгаряне с цел до 600 милиона GMT

GMT DAO spouští průlomovou iniciativu Burn s cílem až 600 milionů GMT

GMT DAO lanza una innovadora iniciativa de quema con un objetivo de hasta 600 millones de GMT

GMT DAO Luncurkan Inisiatif Pembakaran Terobosan dengan Target Hingga 600 Juta GMT

GMT DAO、最大6億GMTを目標とした画期的なバーンイニシアチブを開始

GMT DAO pristato novatorišką deginimo iniciatyvą, kurios tikslas – iki 600 mln. GMT

GMT DAO лансира револуционерна иницијатива за изгореници со цел до 600 милиони GMT

GMT DAO Melancarkan Inisiatif Pembakaran Pecah Tanah Dengan Sasaran Sehingga 600 Juta GMT

GMT DAO GMT මිලියන 600 ක් දක්වා ඉලක්කයක් සමඟ බිම් කඩකිරීමේ පිළිස්සීමේ මුලපිරීම දියත් කරයි

GMT DAO lanserar banbrytande Burn-initiativ med ett mål på upp till 600 miljoner GMT

GMT DAO เปิดตัวโครงการ Burning สุดล้ำด้วยเป้าหมายสูงถึง 600 ล้าน GMT

GMT DAO, 600 Milyon GMT'ye Kadar Hedefle Çığır Açan Yakma Girişimini Başlattı

Stories, News & Mentions about MERUDATA

Merudata’s Stories on HackerNoon