├── LICENSE ├── .gitignore └── README.md /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2023 Melvin Carvalho 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Logs 2 | logs 3 | *.log 4 | npm-debug.log* 5 | yarn-debug.log* 6 | yarn-error.log* 7 | lerna-debug.log* 8 | .pnpm-debug.log* 9 | 10 | # Diagnostic reports (https://nodejs.org/api/report.html) 11 | report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json 12 | 13 | # Runtime data 14 | pids 15 | *.pid 16 | *.seed 17 | *.pid.lock 18 | 19 | # Directory for instrumented libs generated by jscoverage/JSCover 20 | lib-cov 21 | 22 | # Coverage directory used by tools like istanbul 23 | coverage 24 | *.lcov 25 | 26 | # nyc test coverage 27 | .nyc_output 28 | 29 | # Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files) 30 | .grunt 31 | 32 | # Bower dependency directory (https://bower.io/) 33 | bower_components 34 | 35 | # node-waf configuration 36 | .lock-wscript 37 | 38 | # Compiled binary addons (https://nodejs.org/api/addons.html) 39 | build/Release 40 | 41 | # Dependency directories 42 | node_modules/ 43 | jspm_packages/ 44 | 45 | # Snowpack dependency directory (https://snowpack.dev/) 46 | web_modules/ 47 | 48 | # TypeScript cache 49 | *.tsbuildinfo 50 | 51 | # Optional npm cache directory 52 | .npm 53 | 54 | # Optional eslint cache 55 | .eslintcache 56 | 57 | # Optional stylelint cache 58 | .stylelintcache 59 | 60 | # Microbundle cache 61 | .rpt2_cache/ 62 | .rts2_cache_cjs/ 63 | .rts2_cache_es/ 64 | .rts2_cache_umd/ 65 | 66 | # Optional REPL history 67 | .node_repl_history 68 | 69 | # Output of 'npm pack' 70 | *.tgz 71 | 72 | # Yarn Integrity file 73 | .yarn-integrity 74 | 75 | # dotenv environment variable files 76 | .env 77 | .env.development.local 78 | .env.test.local 79 | .env.production.local 80 | .env.local 81 | 82 | # parcel-bundler cache (https://parceljs.org/) 83 | .cache 84 | .parcel-cache 85 | 86 | # Next.js build output 87 | .next 88 | out 89 | 90 | # Nuxt.js build / generate output 91 | .nuxt 92 | dist 93 | 94 | # Gatsby files 95 | .cache/ 96 | # Comment in the public line in if your project uses Gatsby and not Next.js 97 | # https://nextjs.org/blog/next-9-1#public-directory-support 98 | # public 99 | 100 | # vuepress build output 101 | .vuepress/dist 102 | 103 | # vuepress v2.x temp and cache directory 104 | .temp 105 | .cache 106 | 107 | # Docusaurus cache and generated files 108 | .docusaurus 109 | 110 | # Serverless directories 111 | .serverless/ 112 | 113 | # FuseBox cache 114 | .fusebox/ 115 | 116 | # DynamoDB Local files 117 | .dynamodb/ 118 | 119 | # TernJS port file 120 | .tern-port 121 | 122 | # Stores VSCode versions used for testing VSCode extensions 123 | .vscode-test 124 | 125 | # yarn v2 126 | .yarn/cache 127 | .yarn/unplugged 128 | .yarn/build-state.yml 129 | .yarn/install-state.gz 130 | .pnp.* 131 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Activity-LD: A Linked Data Approach to Activity Streams and ActivityPub for Microservices 2 | 3 | ## Abstract 4 | 5 | This note presents "Activity-LD," a framework designed to facilitate the implementation of Activity Streams and ActivityPub in a microservices architecture. In aligning closely with best practices in Linked Data, it ensures backwards compatibility and interoperability with existing systems, promotes user privacy and control, and fosters seamless service transitions. 6 | 7 | ## Introduction 8 | 9 | Activity-LD is a comprehensive solution to manage microservices in a Linked Data context, using the widely adopted standards of Activity Streams and ActivityPub. It comprises small, modular components—including profile, inbox, outbox, and auth modules—that can function independently or collaboratively. As a commitment to universal compatibility and modern development, Activity-LD adheres to all relevant standards. 10 | 11 | ## Principles 12 | 13 | Activity-LD is designed around several key principles: 14 | 15 | 1. **Backwards Compatibility**: Activity-LD is crafted to interact seamlessly with existing systems, thereby fostering adoption and integration without disruption to current operations. 16 | 17 | 2. **Modularity**: Activity-LD is comprised of distinct components that can operate autonomously or in conjunction, offering the flexibility necessary to cater to diverse use cases and architectural needs. 18 | 19 | 3. **Standards Compliance**: As a commitment to interoperability and accessibility, Activity-LD fully complies with established W3C standards, ensuring that any compliant service can interact with it. 20 | 21 | 4. **Best Practices in Linked Data**: Leveraging the power of Linked Data, Activity-LD delivers highly connected, semantically rich data that drives informed decision-making and efficient service coordination. 22 | 23 | ## Compatibility with Existing Systems 24 | 25 | Activity-LD has been built with a clear focus on bridging and adapting to existing systems, such as Solid, Nostr, Mostr, and more. The design philosophy encourages the development of adapters to facilitate communication and data sharing across platforms, promoting a vibrant ecosystem of interdependent services. 26 | 27 | ## User Privacy and Control 28 | 29 | With the growing emphasis on user privacy and data control, Activity-LD integrates features that allow users to own and manage their private keys. This empowers users to control their digital identities, thereby bolstering privacy and enhancing trust in digital services. 30 | 31 | ## Nomadic Identity 32 | 33 | In line with the vision of a flexible and user-centric digital landscape, Activity-LD supports nomadic identities. This allows users to move freely from one service to another, ensuring uninterrupted access to their data and services, and reducing the risk of vendor lock-in. 34 | 35 | ## Conclusion 36 | 37 | Activity-LD is a forward-looking approach to leveraging the power of Linked Data in microservices architecture. By harmonizing Activity Streams and ActivityPub with user privacy and control, it creates a robust, flexible, and standards-compliant framework ready for the future of digital services. 38 | --------------------------------------------------------------------------------