Greetings XSF! Thanks to Mr. Timothée Jaussoin (alias "edhelas") who is responsible for "XEP-0472: Pubsub Social Feed" I am interested and investigate about developing and utilizing XMPP PubSub. I am working on a couple of XMPP chat bots to which I will integrate support for PubSub. * Slixfeed (integrated) Slixfeed is a news bot of which PubSub support is almost done. It will use of affiliation='publisher' as defined in XEP-0060 to post news items to PubSub nodes https://git.xmpp-it.net/sch/Slixfeed * BukuBot (not yet integrated) BukuBot is a new chat bot which I contemplate on adding PubSub support in order to make link directories sharable, yet I do not think it would be wise to utilize node `urn:xmpp:links:0` for this purpose. Because of this, I would like to discuss of a new XEP which probably would be similar to XEP-0277 and XEP-0472, yet it would be specifically aimed at bibliography management. Such XEP would be utilized to share Book and Scholar citations, URLs (Gemini, Gopher, HTTP, XMPP), and other type of references over XMPP PubSub. I would be thankful for you to help and share your thoughts on this matter. Kind regards, Schimon
Greetings, Pardon, I have made a mistake. Please see correction below. On Fri, 7 Jun 2024 13:44:08 +0300 Schimon Jehudah <sch@fedora.email> wrote:
Greetings XSF!
Thanks to Mr. Timothée Jaussoin (alias "edhelas") who is responsible for "XEP-0472: Pubsub Social Feed" I am interested and investigate about developing and utilizing XMPP PubSub.
I am working on a couple of XMPP chat bots to which I will integrate support for PubSub.
* Slixfeed (integrated)
Slixfeed is a news bot of which PubSub support is almost done.
It will use of affiliation='publisher' as defined in XEP-0060 to post news items to PubSub nodes https://git.xmpp-it.net/sch/Slixfeed
* BukuBot (not yet integrated)
BukuBot is a new chat bot which I contemplate on adding PubSub support in order to make link directories sharable, yet I do not think it would be wise to utilize node `urn:xmpp:links:0` for this purpose.
I meant that I do not think it would be wise to utilize node `urn:xmpp:microblog:0` for this purpose, and so I suggest to specify a different node for this purpose; possible nodes would be: - urn:xmpp:bibliography:0 - urn:xmpp:links:0 - urn:xmpp:uris:0
Because of this, I would like to discuss of a new XEP which probably would be similar to XEP-0277 and XEP-0472, yet it would be specifically aimed at bibliography management.
Such XEP would be utilized to share Book and Scholar citations, URLs (Gemini, Gopher, HTTP, XMPP), and other type of references over XMPP PubSub.
I would be thankful for you to help and share your thoughts on this matter.
Kind regards, Schimon
Regards, Schimon
Hi Schimon, can you tell use more about your end goal (end-user use-case)? Is it something for social sharing (e.g. I publish a book I'm reading, I want to allow comments, reactions, repeat, etc.) or is it something like having a collection of books/citation, etc? In the later case, you can have a look at XEP-0346: Form Discovery and Publishing, which is a way to share Data Form over Pubsub, I'm already using it to share various kind of things (TODO list, shopping list, tickets, merge requests), and I have plans for books too. It would actually great to have something usable with both, as both use cases are legitimate, in which case it could be describing the data to share and the fields to use in a Data Form, which could then be used either as attachment in a blog item (e.g. with XEP-0470), or directly with XEP-0346. Best, Goffi Le vendredi 7 juin 2024, 12:57:33 UTC+2 Schimon Jehudah a écrit :
Greetings,
Pardon, I have made a mistake. Please see correction below.
On Fri, 7 Jun 2024 13:44:08 +0300 Schimon Jehudah <sch@fedora.email> wrote:
Greetings XSF!
Thanks to Mr. Timothée Jaussoin (alias "edhelas") who is responsible for "XEP-0472: Pubsub Social Feed" I am interested and investigate about developing and utilizing XMPP PubSub.
I am working on a couple of XMPP chat bots to which I will integrate support for PubSub.
* Slixfeed (integrated)
Slixfeed is a news bot of which PubSub support is almost done.
It will use of affiliation='publisher' as defined in XEP-0060 to post news items to PubSub nodes https://git.xmpp-it.net/sch/Slixfeed
* BukuBot (not yet integrated)
BukuBot is a new chat bot which I contemplate on adding PubSub support in order to make link directories sharable, yet I do not think it would be wise to utilize node `urn:xmpp:links:0` for this purpose.
I meant that I do not think it would be wise to utilize node `urn:xmpp:microblog:0` for this purpose, and so I suggest to specify a different node for this purpose; possible nodes would be:
- urn:xmpp:bibliography:0 - urn:xmpp:links:0 - urn:xmpp:uris:0
Because of this, I would like to discuss of a new XEP which probably would be similar to XEP-0277 and XEP-0472, yet it would be specifically aimed at bibliography management.
Such XEP would be utilized to share Book and Scholar citations, URLs (Gemini, Gopher, HTTP, XMPP), and other type of references over XMPP PubSub.
I would be thankful for you to help and share your thoughts on this matter.
Kind regards, Schimon
Regards, Schimon _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
There doesn't seem to be a need for a well-known node name for this? Unless I'm missing the use case...
Greeting Stephen! There is no special use case other than a dedicated node ID. The purpose is a a concensus node ID which should ease on interoperability betweeen systems. Suppose project Betula (links directory system) adds intergration with XMPP PubSub, and choses "betula" as node ID. https://codeberg.org/bouncepaw/betula/issues/9 BukuBot might expect "buku_public_links" and Movim might expect "movim_social_links" for bookmarks. An inconsistent node ID would hinder interoperability. Having a consensus node ID for this purpose would allow sharing of data without coordinating between projects, only referring to an XEP. Generally, I would suppose that it would be almost the same if not exactly the same as XEP-0472 in structure and data type. If you still think it is not needed, for the time being, please inform me and I will neglect this proposal. It is good to read from you. Best regards, Schimon On Fri, 7 Jun 2024 13:33:45 +0000 Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
There doesn't seem to be a need for a well-known node name for this? Unless I'm missing the use case...
There is no special use case other than a dedicated node ID.
The purpose is a a concensus node ID which should ease on interoperability betweeen systems.
Suppose project Betula (links directory system) adds intergration with XMPP PubSub, and choses "betula" as node ID.
Normally I would expect node id to either be random (such as a UUIDv4) or user selected. Along with a user selected title which is usually what a users will see when browsing.
Good day! I retract from this argument due to XEP-0462: PubSub Type Filtering. Link: https://xmpp.org/extensions/xep-0462.html Thank you Stephen for raising my attention to pubsub#type attribute. On Fri, 7 Jun 2024 18:18:11 +0000 Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
There is no special use case other than a dedicated node ID.
The purpose is a a concensus node ID which should ease on interoperability betweeen systems.
Suppose project Betula (links directory system) adds intergration with XMPP PubSub, and choses "betula" as node ID.
Normally I would expect node id to either be random (such as a UUIDv4) or user selected. Along with a user selected title which is usually what a users will see when browsing.
Best regards, Schimon
Good day Jérôme! Thank you for joining to this thread and sharing insights! Please pardon me for not posting to your post ID. Your message was not delivered to my email.
Hi Schimon,
can you tell use more about your end goal (end-user use-case)?
Is it something for social sharing (e.g. I publish a book I'm reading, I want to allow comments, reactions, repeat, etc.) or is it something like having a collection of books/citation, etc?
It is more similar to the latter: Storing of bibliographic references on PubSub nodes and also publishing and sharing (restricted to authorized contacts) of those references. Bibliography on PubSub: * Storing (privately); * Publishing (publicly); * Sharing (restrictedly). I am currently focued on systems which are commonly referred as "bookmark managers" or "links directories". Example: https://codeberg.org/bouncepaw/betula/issues/9
In the later case, you can have a look at XEP-0346: Form Discovery and Publishing, which is a way to share Data Form over Pubsub, I'm already using it to share various kind of things (TODO list, shopping list, tickets, merge requests), and I have plans for books too.
It would actually great to have something usable with both, as both use cases are legitimate, in which case it could be describing the data to share and the fields to use in a Data Form, which could then be used either as attachment in a blog item (e.g. with XEP-0470), or directly with XEP-0346.
This appears to be a wonderful idea! I will strive to make BukuBot utilizable with PubSub in both fashions you have described.
Best, Goffi
P.S. Please read the following notes. Important notes to understand my thoughts and approach to the subject: 1. I refer to Bibliogrphy as a list of anything textual, not only a reference of articles, books, and other sorts of publications. 2. To me, bibliographic references are mistakenly known as "Bookmarks", "Favorites" (terms used by HTML browsers), "Social Bookmarking Systems" (term used by HTML based systems) etc. and those terms cause for confusion to many people who consequently and inadvertently neglect the potential of posessing (i.e. holding and owning) a personal bibliography. 3. I have a different approach to what some attempt to indoctrinate the public, and I refer to bookmarks, contacts and even magnet links (ed2k, gnutella, torrents) etc. as *bibliography*. 4. To store my contacts, I use a directory with vCards (each contact has its own vCard file. See https://codeberg.org/magdesign/sxmo-userscripts/issues/1 5. Recently, I have been using my bookmarks manager, buku, to store also contacts and magnet links, so I, in fact, use a software (buku), which is originally intended to be a "bookmark manager" (for HTTP links), as a general system for everything which is textual (i.e. bookmarks, contacts (irc, telephony, voip, xmpp), gemini, gopher, magnet links, ssh etc.), albeit buku is not intended for storing this information, it does that task well, and even better than any solution I have been striving to find. See: https://github.com/jarun/buku 6. In a similar context if not in the same context, YaCy search engine, which, like buku, is a links directory system has began as a "bookmarks manager". See: https://yacy.net/ 7. I understand that a "search engine", so called (what does "engine" mean in this context?) is really a jargon which some of the public has been indoctrinated to use, and is actually a links directory - of course it has a larger caching system for text to look up, but it is nevertheless a database of textual links directory of publications (bibliography), just like the one that some HTML browsers have. 8. To me, buku is a static bibliography manager, Falkon is an HTML browser and a static bibliography manager, Liferea (Syndicated Feed Reader) is a dynamic bibliography manager, YaCy, as it also supports Syndicated Feeds, is both a static and a dynamic bibliography manager. 9. XMPP PubSub is all of the above.
Greetings, everyone! I am working on a "social" bookmarking system which is solely based on XMPP PubSub and Atom Syndication Format (i.e. XEP-0277 and XEP-0472). The benefits, as you already know* are: 1. The data is always stored on your account, because the system only provides an interface to make use of your own PubSub in a certain fashion, hence there is no need to worry whether or not the system shuts down or otherwise, so if someone decides to turn it off, someone else can run his own system and your bookmarks are still available. 2. The server does not store the data, so there is no need for a lot of storage to operate it. 3. No registration is required. Only an XMPP account. Note that for statistics and ease of intermediating people inside the system, it is essential to maintain a database, yet not all data has to be stored, which means that if the top 1,000,000 most popular links are important to you, for the sake of keeping the traffic, then there is no need for more than 200MB to 500MB of a storage disk for an SQLite database. * I am writing this information for people from outside of XMPP. Currently, the system is perfectly useable by a one man. Yet, I do need help in enhancing that system to allow access to multiple people at the same time. I was thinking of using the "cookies" system to store sessions and to link the received session value with the one which is store on runtime: accounts[jid] = XmppInstance(jid + '/blasta', password) sessions[jid] = str(random.random()) I am using Pyhton FastAPI and Slixmpp for that task. I would greately appreciate your assistance. Best regards, Schimon On Thu, 13 Jun 2024 14:26:44 +0300 Schimon Jehudah <sch@fedora.email> wrote:
Good day Jérôme!
Thank you for joining to this thread and sharing insights! Please pardon me for not posting to your post ID. Your message was not delivered to my email.
Hi Schimon,
can you tell use more about your end goal (end-user use-case)?
Is it something for social sharing (e.g. I publish a book I'm reading, I want to allow comments, reactions, repeat, etc.) or is it something like having a collection of books/citation, etc?
It is more similar to the latter: Storing of bibliographic references on PubSub nodes and also publishing and sharing (restricted to authorized contacts) of those references.
Bibliography on PubSub: * Storing (privately); * Publishing (publicly); * Sharing (restrictedly).
I am currently focued on systems which are commonly referred as "bookmark managers" or "links directories".
Example: https://codeberg.org/bouncepaw/betula/issues/9
In the later case, you can have a look at XEP-0346: Form Discovery and Publishing, which is a way to share Data Form over Pubsub, I'm already using it to share various kind of things (TODO list, shopping list, tickets, merge requests), and I have plans for books too.
It would actually great to have something usable with both, as both use cases are legitimate, in which case it could be describing the data to share and the fields to use in a Data Form, which could then be used either as attachment in a blog item (e.g. with XEP-0470), or directly with XEP-0346.
This appears to be a wonderful idea!
I will strive to make BukuBot utilizable with PubSub in both fashions you have described.
Best, Goffi
Pardon for posting this message here. The message has been forwarded to JDev and a new friend from Lithuania has promptly helped! I think I want to raise the argument about a new XEP, again. Jérôme and Stephen, I would want to direct an issue to you. I am working on a bookmark sharing system based on PubSub and Atom Syndication Format (i.e. XEP-0277 and XEP-0472). I intend to utilize only the following fields: - Title - Link - Summary (for description) - Category (for tags) I might add content (i.e. storing a whole article as Movim does) in future, but I doubt I would do so soon. Yet I do not think I am interested in having HTML tags inside fields "title" nor "summary", despite Atom Syndication Format allows "type=xhtml" and "type=html" for each. Also, Libervia and Movim might be interested to interact with the system that I am building, and they might determine that HTML tags are fine. 1) Should I ask for a new XEP? 2) Should I clean sanitize, so called, HTML tags from titles and summaries? What should I do? Thank you, Schimon On Thu, 18 Jul 2024 19:29:46 +0300 Schimon Jehudah <sch@fedora.email> wrote:
Greetings, everyone!
I am working on a "social" bookmarking system which is solely based on XMPP PubSub and Atom Syndication Format (i.e. XEP-0277 and XEP-0472).
The benefits, as you already know* are:
1. The data is always stored on your account, because the system only provides an interface to make use of your own PubSub in a certain fashion, hence there is no need to worry whether or not the system shuts down or otherwise, so if someone decides to turn it off, someone else can run his own system and your bookmarks are still available.
2. The server does not store the data, so there is no need for a lot of storage to operate it.
3. No registration is required. Only an XMPP account.
Note that for statistics and ease of intermediating people inside the system, it is essential to maintain a database, yet not all data has to be stored, which means that if the top 1,000,000 most popular links are important to you, for the sake of keeping the traffic, then there is no need for more than 200MB to 500MB of a storage disk for an SQLite database.
* I am writing this information for people from outside of XMPP.
Currently, the system is perfectly useable by a one man.
Yet, I do need help in enhancing that system to allow access to multiple people at the same time.
I was thinking of using the "cookies" system to store sessions and to link the received session value with the one which is store on runtime:
accounts[jid] = XmppInstance(jid + '/blasta', password) sessions[jid] = str(random.random())
I am using Pyhton FastAPI and Slixmpp for that task.
I would greately appreciate your assistance.
Best regards, Schimon
On Thu, 13 Jun 2024 14:26:44 +0300 Schimon Jehudah <sch@fedora.email> wrote:
Good day Jérôme!
Thank you for joining to this thread and sharing insights! Please pardon me for not posting to your post ID. Your message was not delivered to my email.
Hi Schimon,
can you tell use more about your end goal (end-user use-case)?
Is it something for social sharing (e.g. I publish a book I'm reading, I want to allow comments, reactions, repeat, etc.) or is it something like having a collection of books/citation, etc?
It is more similar to the latter: Storing of bibliographic references on PubSub nodes and also publishing and sharing (restricted to authorized contacts) of those references.
Bibliography on PubSub: * Storing (privately); * Publishing (publicly); * Sharing (restrictedly).
I am currently focued on systems which are commonly referred as "bookmark managers" or "links directories".
Example: https://codeberg.org/bouncepaw/betula/issues/9
In the later case, you can have a look at XEP-0346: Form Discovery and Publishing, which is a way to share Data Form over Pubsub, I'm already using it to share various kind of things (TODO list, shopping list, tickets, merge requests), and I have plans for books too.
It would actually great to have something usable with both, as both use cases are legitimate, in which case it could be describing the data to share and the fields to use in a Data Form, which could then be used either as attachment in a blog item (e.g. with XEP-0470), or directly with XEP-0346.
This appears to be a wonderful idea!
I will strive to make BukuBot utilizable with PubSub in both fashions you have described.
Best, Goffi
Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Good day!
I intend to utilize only the following fields: - Title - Link - Summary (for description) - Category (for tags)
I would also intend to make use of a couple of boolean fields. - Private - Read (mark a resource for "reading for later") * For option "private" I might use features provided by XEP-0060. * For option "read" and other custom fields, I might use The "atom:category" Element https://www.rfc-editor.org/rfc/rfc4287#section-4.2.2 So the required Atom fields are: - Title (plain text) - Link - Summary (plain text) - Category (tags) - Category (option read) And the required PubSub features: - Private (manage authorization) A note concerning to tags: Because I want compatibility with other bookmark managers, such as buku, then spaces are allowed, yet are not encouraged. Usage of colons and dots is encouraged instead; For example: brand:jabber country:ireland directory:recipe directory:tutorial license:bsd mr:william.cooper news:telecommunication niche:bookmarks service:isp service:restaurant service:vps store:beverage tutorial:cs tutorial:python tutorial:slixmpp utorial:xmpp etc. The question is: Is this proposed use case justifies a new Atom Over XMPP and PubSub (XEP-0060) based XEP, similar to XEP-0277 and XEP-0472? Please advise, Schimon On Fri, 19 Jul 2024 19:51:12 +0300 Schimon Jehudah <sch@fedora.email> wrote:
Pardon for posting this message here.
The message has been forwarded to JDev and a new friend from Lithuania has promptly helped!
I think I want to raise the argument about a new XEP, again.
Jérôme and Stephen, I would want to direct an issue to you.
I am working on a bookmark sharing system based on PubSub and Atom Syndication Format (i.e. XEP-0277 and XEP-0472).
I intend to utilize only the following fields: - Title - Link - Summary (for description) - Category (for tags)
I might add content (i.e. storing a whole article as Movim does) in future, but I doubt I would do so soon.
Yet I do not think I am interested in having HTML tags inside fields "title" nor "summary", despite Atom Syndication Format allows "type=xhtml" and "type=html" for each.
Also, Libervia and Movim might be interested to interact with the system that I am building, and they might determine that HTML tags are fine.
1) Should I ask for a new XEP? 2) Should I clean sanitize, so called, HTML tags from titles and summaries?
What should I do?
Thank you, Schimon
On Thu, 18 Jul 2024 19:29:46 +0300 Schimon Jehudah <sch@fedora.email> wrote:
Greetings, everyone!
I am working on a "social" bookmarking system which is solely based on XMPP PubSub and Atom Syndication Format (i.e. XEP-0277 and XEP-0472).
The benefits, as you already know* are:
1. The data is always stored on your account, because the system only provides an interface to make use of your own PubSub in a certain fashion, hence there is no need to worry whether or not the system shuts down or otherwise, so if someone decides to turn it off, someone else can run his own system and your bookmarks are still available.
2. The server does not store the data, so there is no need for a lot of storage to operate it.
3. No registration is required. Only an XMPP account.
Note that for statistics and ease of intermediating people inside the system, it is essential to maintain a database, yet not all data has to be stored, which means that if the top 1,000,000 most popular links are important to you, for the sake of keeping the traffic, then there is no need for more than 200MB to 500MB of a storage disk for an SQLite database.
* I am writing this information for people from outside of XMPP.
Currently, the system is perfectly useable by a one man.
Yet, I do need help in enhancing that system to allow access to multiple people at the same time.
I was thinking of using the "cookies" system to store sessions and to link the received session value with the one which is store on runtime:
accounts[jid] = XmppInstance(jid + '/blasta', password) sessions[jid] = str(random.random())
I am using Pyhton FastAPI and Slixmpp for that task.
I would greately appreciate your assistance.
Best regards, Schimon
On Thu, 13 Jun 2024 14:26:44 +0300 Schimon Jehudah <sch@fedora.email> wrote:
Good day Jérôme!
Thank you for joining to this thread and sharing insights! Please pardon me for not posting to your post ID. Your message was not delivered to my email.
Hi Schimon,
can you tell use more about your end goal (end-user use-case)?
Is it something for social sharing (e.g. I publish a book I'm reading, I want to allow comments, reactions, repeat, etc.) or is it something like having a collection of books/citation, etc?
It is more similar to the latter: Storing of bibliographic references on PubSub nodes and also publishing and sharing (restricted to authorized contacts) of those references.
Bibliography on PubSub: * Storing (privately); * Publishing (publicly); * Sharing (restrictedly).
I am currently focued on systems which are commonly referred as "bookmark managers" or "links directories".
Example: https://codeberg.org/bouncepaw/betula/issues/9
In the later case, you can have a look at XEP-0346: Form Discovery and Publishing, which is a way to share Data Form over Pubsub, I'm already using it to share various kind of things (TODO list, shopping list, tickets, merge requests), and I have plans for books too.
It would actually great to have something usable with both, as both use cases are legitimate, in which case it could be describing the data to share and the fields to use in a Data Form, which could then be used either as attachment in a blog item (e.g. with XEP-0470), or directly with XEP-0346.
This appears to be a wonderful idea!
I will strive to make BukuBot utilizable with PubSub in both fashions you have described.
Best, Goffi
Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Good evening, to one and all! The proposed bookmarks system has been published and it works as follows: Nodes are referred to as directories/folders and are managed by Access Models. Public items xmpp:bibliography:0 (Open, Presence, Roster) Private items xmpp:bibliography:private:0 (Authorize, Whitelist) Read items xmpp:bibliography:read:0 (Authorize, Whitelist) Nodes Read and Private are the same, though there might be some rare cases which Private be given access. Node Read is for convenience and is intended to facilitate management of data. The properties of Payload / XML / Atom: Title (text) Summary (text) Link Category * Plain text only. * No HTML allowed. We are considering to make use of Atom attribute "rel" for Link, in cases which targets are accessible in several forms or resources. Examples: * JMP https://blog.jmp.chat/ xmpp:blog.jmp.chat?;node=urn%3Axmpp%3Amicroblog%3A0 * Dig https://digdeeper.club/ http://dv2recs7spoc4vquwnt7gotljvot34i4am4xqsfslhfvdymgjfoa.b32.i2p/ https://digdeeper.her.st/ Yet, I sense that the base properties are complete. Please see screenshots https://git.xmpp-it.net/sch/Blasta/src/branch/main/screenshot The Blasta system, as a sharing platform, is still in testing, yet it seems to be fully operational, *and* the bookmarking practice per JID appears to be stable and valid. Shall we define an XEP for bookmarking system, similarly to urn:xmpp:microblog:0 of Libervia and Movim? Link: https://git.xmpp-it.net/sch/Blasta Kind regards, Schimon On Sun, 21 Jul 2024 13:43:41 +0300 Schimon Jehudah <sch@fedora.email> wrote:
Good day!
I intend to utilize only the following fields: - Title - Link - Summary (for description) - Category (for tags)
I would also intend to make use of a couple of boolean fields.
- Private - Read (mark a resource for "reading for later")
* For option "private" I might use features provided by XEP-0060. * For option "read" and other custom fields, I might use The "atom:category" Element https://www.rfc-editor.org/rfc/rfc4287#section-4.2.2
So the required Atom fields are: - Title (plain text) - Link - Summary (plain text) - Category (tags) - Category (option read)
And the required PubSub features: - Private (manage authorization)
A note concerning to tags:
Because I want compatibility with other bookmark managers, such as buku, then spaces are allowed, yet are not encouraged.
Usage of colons and dots is encouraged instead; For example:
brand:jabber country:ireland directory:recipe directory:tutorial license:bsd mr:william.cooper news:telecommunication niche:bookmarks service:isp service:restaurant service:vps store:beverage tutorial:cs tutorial:python tutorial:slixmpp utorial:xmpp etc.
The question is:
Is this proposed use case justifies a new Atom Over XMPP and PubSub (XEP-0060) based XEP, similar to XEP-0277 and XEP-0472?
Please advise, Schimon
On Fri, 19 Jul 2024 19:51:12 +0300 Schimon Jehudah <sch@fedora.email> wrote:
Pardon for posting this message here.
The message has been forwarded to JDev and a new friend from Lithuania has promptly helped!
I think I want to raise the argument about a new XEP, again.
Jérôme and Stephen, I would want to direct an issue to you.
I am working on a bookmark sharing system based on PubSub and Atom Syndication Format (i.e. XEP-0277 and XEP-0472).
I intend to utilize only the following fields: - Title - Link - Summary (for description) - Category (for tags)
I might add content (i.e. storing a whole article as Movim does) in future, but I doubt I would do so soon.
Yet I do not think I am interested in having HTML tags inside fields "title" nor "summary", despite Atom Syndication Format allows "type=xhtml" and "type=html" for each.
Also, Libervia and Movim might be interested to interact with the system that I am building, and they might determine that HTML tags are fine.
1) Should I ask for a new XEP? 2) Should I clean sanitize, so called, HTML tags from titles and summaries?
What should I do?
Thank you, Schimon
On Thu, 18 Jul 2024 19:29:46 +0300 Schimon Jehudah <sch@fedora.email> wrote:
Greetings, everyone!
I am working on a "social" bookmarking system which is solely based on XMPP PubSub and Atom Syndication Format (i.e. XEP-0277 and XEP-0472).
The benefits, as you already know* are:
1. The data is always stored on your account, because the system only provides an interface to make use of your own PubSub in a certain fashion, hence there is no need to worry whether or not the system shuts down or otherwise, so if someone decides to turn it off, someone else can run his own system and your bookmarks are still available.
2. The server does not store the data, so there is no need for a lot of storage to operate it.
3. No registration is required. Only an XMPP account.
Note that for statistics and ease of intermediating people inside the system, it is essential to maintain a database, yet not all data has to be stored, which means that if the top 1,000,000 most popular links are important to you, for the sake of keeping the traffic, then there is no need for more than 200MB to 500MB of a storage disk for an SQLite database.
* I am writing this information for people from outside of XMPP.
Currently, the system is perfectly useable by a one man.
Yet, I do need help in enhancing that system to allow access to multiple people at the same time.
I was thinking of using the "cookies" system to store sessions and to link the received session value with the one which is store on runtime:
accounts[jid] = XmppInstance(jid + '/blasta', password) sessions[jid] = str(random.random())
I am using Pyhton FastAPI and Slixmpp for that task.
I would greately appreciate your assistance.
Best regards, Schimon
On Thu, 13 Jun 2024 14:26:44 +0300 Schimon Jehudah <sch@fedora.email> wrote:
Good day Jérôme!
Thank you for joining to this thread and sharing insights! Please pardon me for not posting to your post ID. Your message was not delivered to my email.
Hi Schimon,
can you tell use more about your end goal (end-user use-case)?
Is it something for social sharing (e.g. I publish a book I'm reading, I want to allow comments, reactions, repeat, etc.) or is it something like having a collection of books/citation, etc?
It is more similar to the latter: Storing of bibliographic references on PubSub nodes and also publishing and sharing (restricted to authorized contacts) of those references.
Bibliography on PubSub: * Storing (privately); * Publishing (publicly); * Sharing (restrictedly).
I am currently focued on systems which are commonly referred as "bookmark managers" or "links directories".
Example: https://codeberg.org/bouncepaw/betula/issues/9
In the later case, you can have a look at XEP-0346: Form Discovery and Publishing, which is a way to share Data Form over Pubsub, I'm already using it to share various kind of things (TODO list, shopping list, tickets, merge requests), and I have plans for books too.
It would actually great to have something usable with both, as both use cases are legitimate, in which case it could be describing the data to share and the fields to use in a Data Form, which could then be used either as attachment in a blog item (e.g. with XEP-0470), or directly with XEP-0346.
This appears to be a wonderful idea!
I will strive to make BukuBot utilizable with PubSub in both fashions you have described.
Best, Goffi
Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
participants (3)
-
Goffi -
Schimon Jehudah -
Stephen Paul Weber