Clepit

বেশির ভাগ রিচ টেক্সট ডেটাবেসে HTML-এর একটি তাল হিসেবে জমা হয়। সেটি দেখানো ছাড়া অন্য কিছু করতে না চাওয়া পর্যন্ত এতে সমস্যা নেই: কোনও গ্রাহকের উল্লেখ আছে এমন প্রতিটি পৃষ্ঠা খুঁজে বার করা, একই নথি ওয়েব পেজ, ইমেল ও মোবাইল অ্যাপে দেখানো, কিংবা দুজনকে একসঙ্গে সম্পাদনা করতে দেওয়া যাতে কারও অনুচ্ছেদ হারিয়ে না যায়। ততক্ষণে শব্দ আর তার সাজসজ্জা জট পাকিয়ে গেছে, আর নথিটি নির্ভরযোগ্যভাবে পড়তে পারে কেবল সেই এডিটর যেটি লিখেছিল।

Clepit দুটিকে আলাদা রাখে। একটি পৃষ্ঠা হল ব্লকের তালিকা, প্রতিটি ব্লক একটি ছোট টাইপ করা বস্তু, আর নথিটি JSON: পার্স করার মতো কোনও মার্কআপ নেই, পড়ার জন্য কোনও এডিটরও লাগে না। এ কারণেই এডিটরটি নিজে নিজেই দাঁড়াতে পারে। @clepit/core npm-এ MIT লাইসেন্সে প্রকাশিত এবং হোস্ট করা দিকটি সম্পর্কে কিছুই জানে না, আর app.clepit.com-এর ওয়ার্কস্পেস হল সেই একই নথিগুলো যখন সহলেখক, অনুমতি, ইতিহাস এবং প্রকাশ্য ওয়েবে একটি ঠিকানা পায়।

পৃষ্ঠা হল ব্লকের একটি তালিকা

একটি ব্লক চারটি ক্ষেত্র: একটি আইডি, একটি টাইপ, সেই টাইপ যে ডেটা নির্ধারণ করে, এবং তার উপর প্রয়োগ করা যেকোনও টিউন। অনুচ্ছেদের ডেটার আকার টেবিলের ডেটার থেকে আলাদা, আর কোন আকার আশা করতে হবে তা টাইপই বলে দেয়, ফলে সংরক্ষিত নথি নিছক পার্স করার বদলে যাচাই করা যায়। পুরো পৃষ্ঠাটি হল একটি সময়চিহ্ন, একটি সংস্করণ এবং ক্রমানুসারে ব্লকগুলো, যা নিজের চোখে পড়ার মতো এবং পুল রিকোয়েস্টে পর্যালোচনা করার মতোই ছোট। পৃষ্ঠাটি দেখতে কেমন হবে তার কোনও বর্ণনা এর ভিতরে নেই: সেটি যে আঁকছে তার এক্তিয়ার। এ কারণেই একটি নথি তিনটি অনুলিপি ছাড়াই ওয়েব পেজ, ইমেল ও মোবাইল স্ক্রিন হয়ে উঠতে পারে।

ব্রাউজার ছাড়াই নথি আঁকা

রেন্ডারার কখনও সরাসরি ব্রাউজারে লেখে না। এটি একটি পাতলা স্তরের ভিতর দিয়ে আঁকে, যার পিছনে দুটি ব্যাকিং আছে: একটি সত্যিকারের পেজ নোড বানায়, অন্যটি স্ট্রিং বানায়, আর একই ব্লক কোড দুটোতেই চলে। এভাবেই প্রকাশিত পৃষ্ঠা এমন সার্ভারে আঁকা হয় যেখানে কোনও ব্রাউজার নেই, আর এ কারণেই সার্ভার যা তৈরি করে তা এডিটর যা দেখাত সেই একই নথি, দ্বিতীয় কোনও বাস্তবায়ন নয় যা ধীরে ধীরে বেঠিক হয়ে পড়ে। স্ট্রিং ব্যাকিং একটি স্যানিটাইজারকে বাধ্যতামূলক আর্গুমেন্ট হিসেবে নেয় এবং ইচ্ছাকৃতভাবেই এর কোনও ডিফল্ট নেই: প্যাকেজের চেনা স্যানিটাইজারটি পার্স করার জন্য একটি পেজ বানায়, তাই সেখানে চলতে পারে না, আর চুপচাপ এসকেপিং-এ ফিরে গেলে প্রতিটি নথির ভিতরের ফরম্যাটিং কিছু না বলেই মুছে যেত। তাই ফাঁকটি ডিফল্টের ভিতরে লুকিয়ে না রেখে যেখানে ব্যবহার হয় সেখানেই দৃশ্যমান রাখা হয়েছে।

পড়তে পাঠকের কোনও JavaScript লাগে না

React অ্যাডাপ্টারটি তার দুই অর্ধকে আলাদা করে পাঠায়, কারণ তারা পরস্পরবিরোধী জিনিস চায়। কনটেন্ট কম্পোনেন্টটি সার্ভারে চলে এবং পৃষ্ঠা তৈরি হওয়ার সময়েই সম্পূর্ণ মার্কআপ বার করে দেয়, ফলে পাঠক প্রথম উত্তরেই নথিটি পেয়ে যান। এডিটর কম্পোনেন্টটি কেবল ক্লায়েন্টে চলে, কারণ সেটি এডিটরের জীবনচক্র সামলায়, আর ব্রাউজার না থাকা পর্যন্ত সামলানোর কিছুই থাকে না। তাই একটি Clepit নথি পড়তে কোনও JavaScript-ই লাগে না। লেখার সময়েই রানটাইম এসে হাজির হয়।

একটি পৃষ্ঠা কী কী ধরে রাখতে পারে

প্যাকেজের সঙ্গে ছাব্বিশ রকমের ব্লক আসে। বেশির ভাগই যেকোনও এডিটরের যা লাগে তাই: হেডিং, অনুচ্ছেদ, তালিকা, চেকলিস্ট, উদ্ধৃতি, কোড, টেবিল, ছবি, অডিও, ভিডিও, ফাইল, কলআউট ও বিভাজক। বাকিগুলো আছে কারণ ডকুমেন্টেশন লিখতে গেলে এমন কিছু দরকার হয় যা সাধারণ লেখার সরঞ্জাম উপেক্ষা করে। একটি সূচিপত্র যা নথির হেডিং থেকে নিজেই তৈরি হয় এবং প্রতিটির সঙ্গে লিঙ্ক করে। ভাঁজ করা যায় এমন অংশ ও কলাম। অন্য একটি পৃষ্ঠার হয়ে দাঁড়ানো কার্ড। হাতে আঁকা স্কেচ। আর একটি কার্যকলাপ ব্লক যা কোন নথিকে দেখতে হবে তা জমা রাখে, তার কার্যকলাপের অনুলিপি নয়, ফলে যেদিন বসানো হয়েছিল সেদিনেই জমে না গিয়ে এখন যা ঘটছে তা দেখাতে থাকে। ব্লকের ভিতরের ফরম্যাটিং সাধারণ চিহ্নগুলো ঢাকে, অর্থাৎ বোল্ড, ইটালিক, আন্ডারলাইন, স্ট্রাইকথ্রু, ইনলাইন কোড, হাইলাইট ও লিঙ্ক, তার সঙ্গে টুলটিপ, স্ট্যাটাস চিপ ও মেনশন। প্যাকেজটির কোনও রানটাইম নির্ভরতা নেই।

সূত্র ও ডায়াগ্রাম, প্যাকেজের ভিতরেই আঁকা

ওই ব্লকগুলোর মধ্যে দুটি LaTeX ও Mermaid দেখায়, আর দুটোই পুরো কাজটা প্যাকেজের ভিতরে করে: উৎস পার্স করে, বিন্যাস হিসেব করে, ফলাফল আঁকে। এর নিচে কোনও রেন্ডারিং লাইব্রেরি নেই, আর কোনও সূত্র বা ফ্লোচার্টকে ছবিতে বদলাতে কোনও পরিষেবার কাছে ডাকও যায় না। এটা নির্ভরতা নিয়ে পছন্দের চেয়ে বরং স্ট্রিং ব্যাকিং-এর পরিণতি। যে ব্লক কেবল ব্রাউজারই দেয় এমন কিছুর দিকে, বা নেটওয়ার্কের দিকে হাত বাড়াত, সেটি প্রকাশিত পৃষ্ঠা পরিবেশনকারী সার্ভারে আঁকাই যেত না, আর তখন কে চাইছে তার উপর ভিত্তি করে পৃষ্ঠাটি আলাদা আলাদা দেখাত।

পৃষ্ঠার ভিতরেই বাস করে এমন একটি API রেফারেন্স

OpenAPI ব্লকটিকে একটি স্পেসিফিকেশন দিন, পেস্ট করে বা ঠিকানা দিয়ে, আর সেটি স্পেসিফিকেশন যা বর্ণনা করে তা-ই আঁকে: অপারেশনগুলো, তাদের পাথ ও প্যারামিটার, রিকোয়েস্ট ও রেসপন্স স্কিমা, এবং প্রমাণীকরণের পদ্ধতি। প্রতিটি অপারেশনের জন্য এটি cURL, TypeScript, Dart ও Python-এ একটি রিকোয়েস্ট স্নিপেটও বানায়, যা স্পেসিফিকেশন থেকে তৈরি, কোনও লেখকের হাতে টাইপ করা নয় যিনি হালনাগাদ করতে ভুলে যাবেন। embed ব্লকটিও বাইরের জগৎকে একই চোখে দেখে: যে গুটিকয় পরিষেবা সে সত্যিই দেখাতে পারে সেগুলো চেনে, বাকি সবের জন্য সাধারণ একটি লিঙ্ককে ব্যর্থতা নয় বরং যথাযথ ফলাফল হিসেবে ধরে, আর যে ঠিকানাকে সে বিশ্বাস করে না তা আঁকতে স্পষ্টভাবেই অস্বীকার করে।

একই অনুচ্ছেদে দুজন মানুষ

সরাসরি সম্পাদিত হচ্ছে এমন একটি পৃষ্ঠা সার্ভারে একটিমাত্র টাস্ক ধরে রাখে, প্রতি পৃষ্ঠায় একটি, আর প্রতিটি আপডেট ক্রমানুসারে তার মধ্য দিয়েই যায়। এ কারণেই একসঙ্গে সম্পাদনা নিয়ে ভাবা সহজ: প্রথমজনের সঙ্গে পাল্লা দেওয়ার মতো দ্বিতীয় কোনও লেখক নেই। নথিটি নিজেই একটি CRDT, তাই একই অনুচ্ছেদে টাইপ করা দুজন মানুষের কাজ মুছে না গিয়ে মিশে যায়, আর পিছিয়ে পড়া কোনও ক্লায়েন্ট দুই পক্ষের যা যা নেই তা বিনিময় করে ধরে ফেলে। প্রতিটি আপডেট কারও কাছে সম্প্রচারিত হওয়ার আগেই একটি রাইট-অ্যাহেড লগে যুক্ত হয়, ফলে নথিতে থাকা অন্যরা যা দেখেন তা আগেই স্থায়ীভাবে নথিভুক্ত, নিছক রিলে করা নয়। অনুমতি ইন্টারফেসে নয়, সার্ভারেই প্রয়োগ হয়: সম্পাদনার অধিকার ছাড়া যোগ দেওয়া কেউ পড়ায় নেমে যান, আর নথি খোলা থাকা অবস্থায় সেশনটি সেই অধিকার নিয়মিত আবার যাচাই করে, ফলে কেড়ে নেওয়া অনুমতি পৃষ্ঠা রিলোডের অপেক্ষা না করে ইতিমধ্যেই টাইপ করছেন এমন কারও উপর গিয়ে পড়ে।

প্রতিটি লেখা একটিই দরজা দিয়ে যায়

একটি নথি বদলাতে পারেন তাতে টাইপ করা কোনও মানুষ, আবার API ডাকা কোনও প্রোগ্রামও, এবং এই দুই পথ আগে একই পৃষ্ঠায় আলাদাভাবে লিখতে পারত। এখন আর পারে না। API-এর লেখা সেই একই সেশনে পাঠিয়ে দেওয়া হয় যেটি সরাসরি নথিটি ধরে আছে, সেখানে তা সরাসরি সম্পাদনার পাশে একটিই ট্রানজ্যাকশন হিসেবে প্রয়োগ হয়, ফলে পৃষ্ঠাটি কী বলছে সে বিষয়ে আলাদা মত রাখা দুই লেখকের বদলে ঘটনার একটিই ক্রম থাকে। নথিটি ফিরিয়ে লেখার সময় ব্লক আইডি অক্ষত রাখা হয়, কারণ মন্তব্যগুলো সেগুলোর সঙ্গে নোঙর করা, আর নতুন আইডি বানানো কোনও রিকনসাইল প্রতিটি মন্তব্যকে শূন্যের দিকে তাক করিয়ে রেখে যেত। আর ফলস্বরূপ ব্লক-সেটটি যখন আগে থেকে জমা থাকা সেটের অবিকল সমান, তখন কিছুই লেখা হয় না।

একটিমাত্র ট্রান্সপোর্ট যেখানে মেশিন কি পৌঁছাতে পারে না

একটি ব্যক্তিগত API কি REST, GraphQL, GraphQL সাবস্ক্রিপশন সকেট এবং MCP-এর বিরুদ্ধে কাজ করে। কোলাবরেশন সকেটে সেটি কাজ করে না, আর তা ইচ্ছাকৃত। প্রতিটি সহযোগী পরিবর্তনে যিনি করেছেন তাঁর ছাপ পড়ে, আর সেই ছাপগুলোই পৃষ্ঠার ইতিহাসে লিপিবদ্ধ কর্তৃত্ব হয়ে ওঠে। সেখানে কোনও যন্ত্র-পরিচয় সম্পাদনা করলে এমন একজন লেখক লেখা হত যা কোনও মানুষ লেখেনি, আর পরে তা ফেরানো মানে একটি সারি মুছে ফেলা নয়, ইতিহাস নতুন করে লেখা। বিভাজনরেখাটি ওয়েবসকেট আর HTTP-এর মধ্যে নয়: প্রশ্নটি হল ট্রান্সপোর্টটি কর্তৃত্বসহ ইতিহাস লেখে কি না। নিয়মটি স্মৃতির ভরসায় নয়, কোডের গড়নেই বলবৎ, কারণ কি গ্রহণ করতে হলে ইচ্ছাকৃতভাবে অন্য একটি প্রমাণীকরণ কল বেছে নিতে হয়, আর কোনও ট্রান্সপোর্ট তা করলে একটি টেস্ট ব্যর্থ হয়।

নিজস্ব ঠিকানায় একটি ওয়ার্কস্পেস

প্রতিটি ওয়ার্কস্পেসই একটি টেন্যান্ট, তৈরি হওয়ার মুহূর্ত থেকেই তার নিজস্ব সাবডোমেন থাকে, আর অনুরোধটি যে ঠিকানায় এসেছে সেখান থেকেই টেন্যান্ট নির্ধারিত হয়। তাই আপনি কোন টেন্যান্টে আছেন তা আপনার কোনও ডেটা পড়ার আগেই ঠিক হয়ে যায়, পরে প্রয়োগ করা কোনও ফিল্টার দিয়ে নয় যা কেউ ভুলে যেতে পারে। তার নিচে ডেটাবেস নিজেই সারি-স্তরের নিরাপত্তার মাধ্যমে সীমানাটি বলবৎ করে: প্রতিটি অনুরোধ একটি সংযোগ নেয়, তাতে আহ্বানকারীর পরিচয় ছাপ দেয়, আর সংযোগটি ফেরত গেলে পুল সেই অবস্থা মুছে দেয়, ফলে এক অনুরোধের পরিচয় পরের অনুরোধের কোয়েরিতে চুইয়ে পড়তে পারে না।

ডোমেন দাবি করা আর তা প্রমাণ করা এক নয়

এন্টারপ্রাইজ প্ল্যানে থাকা একটি ওয়ার্কস্পেস নিজের ডোমেন থেকেই তার পৃষ্ঠাগুলো পরিবেশন করতে পারে। ডোমেন দাবি করা আর সেখান থেকে পরিবেশন করা ইচ্ছাকৃতভাবেই আলাদা দুটি ধাপ: ডোমেনটি অযাচাইকৃত অবস্থায় জমা থাকে, আর DNS-এ যাচাইয়ের রেকর্ড না আসা পর্যন্ত রিজলভার সেটিকে পুরোপুরি উপেক্ষা করে। যে কেউ একটি ফর্মে অন্য কোম্পানির ঠিকানা লিখে দিতে পারেন। কিন্তু কেবল যিনি সেই ডোমেন নিয়ন্ত্রণ করেন তিনিই সেই রেকর্ডটি প্রকাশ করতে পারেন যা একে সক্রিয় করে।

পৃষ্ঠাটির যত সংস্করণ ছিল

Clepit একটিমাত্র বর্তমান অবস্থা নয়, সংস্করণ রেখে দেয়। মানুষ কাজ করার সময়েই আপনাআপনি স্ন্যাপশট নেওয়া হয়, তবে এমনভাবে নিয়ন্ত্রিত যাতে সাধারণ টাইপিং শত শত স্ন্যাপশট না বানায়: দশ মিনিট পেরোলে বা দশটি ব্লক বদলালে, যেটি আগে ঘটে, নতুন একটি লেখা হয়। ফিরিয়ে আনা একটিই ট্রানজ্যাকশন: পুরোনো স্ন্যাপশট প্রয়োগ হয়, ব্লকগুলো মেলানো হয়, আর ফিরিয়ে আনাটাই নতুন একটি সংস্করণ হিসেবে লেখা হয়, ফলে পিছিয়ে যাওয়া চুপচাপ মুছে না গিয়ে নথিভুক্ত থাকে। মেলানোর সময় উৎসের ব্লক আইডি ইচ্ছাকৃতভাবেই রক্ষা করা হয়, কারণ মন্তব্য ব্লকের সঙ্গে নোঙর করা, আর নতুন আইডি নিয়ে পৃষ্ঠা ফেরালে তার প্রতিটি মন্তব্য নোঙরহীন হয়ে পড়ত।

আবার খুঁজে পাওয়া

সার্চ চলে পৃষ্ঠাগুলোর একটি প্রক্ষেপণের উপর, আর কোয়েরিটি হাতে SQL-এ জোড়া না লাগিয়ে Postgres-এর নিজস্ব ওয়েব-সার্চ পার্সারের ভিতর দিয়ে যায়, ফলে কেউ উদ্ধৃতিচিহ্ন বা বিয়োগচিহ্ন টাইপ করতে পারেন এবং তার কোনওটাই ইনজেকশনের সুযোগ তৈরি করে না। তবে একটি যৌথ ওয়ার্কস্পেসের জন্য আসল কথা হল অনুমতির যাচাইটি কোথায় বসে। সার্চ pages টেবিলের সঙ্গে জয়েন করে, আর সেই টেবিলের সারি-স্তরের নিরাপত্তা সেই জয়েনেই প্রযোজ্য, ফলে ফলাফল আগে থেকেই সেই পৃষ্ঠাগুলোতে সীমাবদ্ধ যেগুলো প্রশ্নকর্তা দেখতে পারেন। ফিল্টারগুলো, অর্থাৎ পৃষ্ঠা-বৃক্ষের একটি শাখা, কে শেষ সংশোধন করেছেন, কখন শেষ সম্পাদনা হয়েছে, তার উপরে অতিরিক্ত শর্ত হিসেবে যুক্ত হয়। প্রতিটিই সংকুচিত করে; কোনওটিই প্রসারিত করতে পারে না, কারণ সবগুলোই সেই একই যাচাইয়ের পিছনে বসে।

প্রকাশ জমিয়ে দেয়, ভাগ করা দেয় না

এ দুটি আলাদা জিনিস, আর Clepit ইচ্ছাকৃতভাবেই এদের আলাদাভাবে সামলায়। কোনও পৃষ্ঠা প্রকাশ করলে বর্তমান নথিটি একটি সংস্করণ হিসেবে জমে যায়, পৃষ্ঠাটিকে সেদিকে তাক করা হয়, আর সেটি সর্বজনীন হয়: একজন দর্শক clepit.space-এ, acme.clepit.space/handbook-এর মতো ঠিকানায়, যা পড়েন তা সেই জমে যাওয়া সংস্করণ, তারপরে করা সম্পাদনা নয়। প্রকাশ বাতিল করলে নির্দেশকগুলো মুছে যায় কিন্তু সর্বজনীন ঠিকানাটি থেকে যায়, ফলে পরে আবার প্রকাশ করলে সেই একই ঠিকানাতেই ফেরা যায়, তার দিকে যাওয়া সব লিঙ্ক ভেঙে না গিয়ে। শেয়ার লিঙ্ক ঠিক উল্টো: সেটি জীবন্ত নথিটিই পরিবেশন করে, তাই প্রাপক যা দেখেন তা পৃষ্ঠা বদলানোর সঙ্গে সঙ্গেই বদলায়।

এমন একটি লিঙ্ক যা ফিরিয়ে নেওয়া যায়

শেয়ার লিঙ্ক হল একটি টোকেন যা আপনি বাতিল করতে পারেন, আর তৈরির সময়েই তাতে মেয়াদ বসিয়ে দেওয়া যায়। কেবল টোকেনটির হ্যাশ জমা থাকে, তাই লিঙ্কটি তৈরির সময় একবারই দেখানো হয় এবং তারপর ডেটাবেস থেকে তা আর উদ্ধার করা যায় না, আমাদের পক্ষেও নয়, সেখানে পৌঁছায় এমন কারও পক্ষেও নয়। এই লিঙ্কগুলো পড়ার অধিকার দেয়, মন্তব্যের নয়: মন্তব্যের জন্য একজন লেখক লাগে, আর লিঙ্ক হাতে থাকা কেউ লেখক নন।

নিজের ডিরেক্টরি থেকেই সাইন ইন

একটি ওয়ার্কস্পেস প্রমাণীকরণের ভার নিজের আইডেন্টিটি প্রোভাইডারের হাতে তুলে দিতে পারে: বিজনেস প্ল্যানে OpenID Connect, এন্টারপ্রাইজে SAML, আর তার পাশে ডিরেক্টরি সমন্বয়ের জন্য SCIM। Okta ও Entra বাস্তবে যে ইউজার রিসোর্সটি চালায় SCIM সেটিই সামলায়, আর মানকের সরল পাঠ থেকে একটি ইচ্ছাকৃত বিচ্যুতি ঘটায়: ডিলিট করলে সদস্যকে মুছে না ফেলে নিষ্ক্রিয় করা হয়। স্পেসিফিকেশন এটি অনুমোদন করে, আর বিকল্পটি হল এমন এক ডিরেক্টরি সমন্বয় যা কাউকে কোনও গ্রুপ থেকে সরিয়ে দিয়েই একটি ওয়ার্কস্পেসের সব কনটেন্ট ধ্বংস করে দিতে পারে।

এর সঙ্গে কথা বলার চারটি উপায়

REST /v1-এর নিচে চুয়াল্লিশটি অপারেশন সামলায়, যেগুলোর বর্ণনা দেয় রুট থেকেই তৈরি হওয়া একটি OpenAPI নথি, পাশে হাতে লেখা কিছু নয়; আর CI সেই ফলাফলকে জমা থাকা কপির সঙ্গে মিলিয়ে দেখে, ফলে রেজিস্ট্রি এড়িয়ে যাওয়া কোনও রুট পরিবর্তন চুপচাপ ঢুকে পড়তে পারে না। GraphQL অ্যাপ্লিকেশন মডেলটি সামলায় এবং নিজস্ব সকেটে সাবস্ক্রিপশন বহন করে। রিয়েলটাইম একটি আলাদা প্রক্রিয়া, আর সেজন্যই গেটওয়ে রিস্টার্ট করলে অনুরোধের পৃষ্ঠতলটি সঙ্গে পড়ে যায় না; এবং এটি রুম ধরে নয়, সকেট ধরে অনুমোদন দেয়: প্রতিটি ইভেন্টের জন্য টেন্যান্টের প্রতিটি সংযোগ একটিই সমষ্টিগত যাচাইয়ে বিবেচিত হয়, আর কেবল যাদের দেখার অনুমতি আছে তারাই সেটি পায়। MCP সেই একই অপারেশনগুলো AI এজেন্টদের কাছে টুল হিসেবে খুলে দেয়, আর কোন ওয়ার্কস্পেসে কাজ করছে তা ঠিক করতে কোনও টুলই আহ্বানকারীর দেওয়া আইডি বিশ্বাস করে না; লেখাগুলো ইন্টারফেস যে সার্ভিসগুলো ব্যবহার করে সেগুলোর মধ্য দিয়েই যায়, তাই অনুমতির যাচাই আর অডিট ট্রেল একই।

কাদের জন্য

যেসব দলের নিজেদের নিয়ন্ত্রণে থাকা এডিটর দরকার, এবং যেসব ডেভেলপার নিজেদের প্রোডাক্টে কাঠামোবদ্ধ কনটেন্ট যুক্ত করেন।

ভিজিট করুন Clepit: clepit.com