Replies: 10 comments 9 replies
-
|
Interesting idea. Could you explain why would it be beneficial to the projects/users? |
Beta Was this translation helpful? Give feedback.
-
|
I have added a couple of projects:
I have notified project linkding I have announced of my intention to be compatible with XMPP publishing systems such as Libervia and Movim I have wrote a post about it at my journal
Even though I was aware that HTML based annotation system is in fact a publishing system, I did not intend for Blasta to be absolutely compatible with publishing systems, yet the structure, of posts of Libervia and Movim which are based upon Atom Syndication Format, is identical by almost 100% if not by a 100%. @asciimoo Because your system is compatible with ActivityPub, how close is it to be an optional publishing system? |
Beta Was this translation helpful? Give feedback.
-
|
@sjehuda I don't know what is the definition of a publishing system, but omnom is a functional ActivityPub actor. If you follow an Omnom user via ActivityPub, you get the new bookmarks. |
Beta Was this translation helpful? Give feedback.
-
|
I define bookmarks management systems as publishing systems.
I do intend to add an ActivityPub intreface to Blasta, in addition to
its XMPP interface, so that it interoperates with Omnom and Postmarks.
|
Beta Was this translation helpful? Give feedback.
-
|
I am still thinking of it, and I am thinking, for sometime already, to harmonize the bookmarks database of Blasta (and other projects such as Slixfeed) with the structure of The Atom Syndication Format (RFC 4287). I think that a database which would conform with The Atom Syndication Format is hthe best that we can have, because The Atom Syndication Format has all the required elements for posts, including "related" links, "enclosures" links. So, just as with project "linkding/" we can bookmark URI https://omnom.zone/ with a description (i.e. atom:summary), and even further notes of our own (i.e. atom:content), and add URI https://nlnet.nl/project/Omnom/ and URI https://*******.com/asciimoo/omnom as related links; and this is standardized by conforming with The Atom Syndication Format, which is the great advantage. I intend to do so; and I hope that the developers here would be fond of it. Internal references. |
Beta Was this translation helpful? Give feedback.
-
|
Is part of the goal with this idea, @sjehuda, for interoperability between services in terms of "following" users? As someone who has been thinking about these technologies recently, and has been playing about with linkhut, something that been a bit sad is the lack interoperability in terms of following & aggregation. To address part of @asciimoo's comments, ActivityPub (to my ignorant knowledge) is a different beast in so much as it requires dynamic actions on the part of the server that are not possible with statically generated sites or simple clients. If we are able to standardize on a (auxiliary or otherwise) Atom feed format, then it opens us up to passive listeners or statically generated/transient systems should be able to consume and aggregate data more akin to RSS readers. Although this is an technical oversimplification and misrepresentation, ActivityPub feels like a Atom/RSS-superset that allows for user interaction that, while it is more powerful, is technically more complex & demanding. However, I think in a bookmark sharing system this doesn't necessarily need to be the case. For example, in linkhut, I can just copy a user's posted link into my personal link feed. All that feature requires is a RSS/Atom feed but without a standardized interface across similar platforms it could be difficult to have bridges across these systems. In terms of a project like buku, Atom could easily be an export backend. If I export the Atom xml to a path on my webserver (or a static-site host), then I can serve my bookmarks to consumers without needing a full ActivityPub instance. From there, users on other services (or in their RSS/Atom readers) could aggregate what I'm publishing and copy links as they please. Did I mischaracterize the spirit of this idea @sjehuda ? |
Beta Was this translation helpful? Give feedback.
-
|
I've never said that ActivityPub is superior or preferable over RSS/Atom nor vice versa. Both have their advantages and weaknesses, that's why Omnom supports both (and standard JSON REST API as well). Either users who are part of the Fediverse or who prefer RSS readers or just quickly want to grab the results with a curl + jq oneliner combo, can enjoy the output this way.
No standardization can solve the issue of a data provider deciding to filter/limit the provided data. Instead of talking about standardization, every system should provide as much data/format as possible and then users can filter it how they want - in my opinion. |
Beta Was this translation helpful? Give feedback.
-
|
On Tue, 04 Nov 2025 07:45:43 -0800 Frederick Morlock ***@***.***> wrote:
Is part of the goal with this idea, @sjehuda, for interoperability
between services in terms of "following" users? As someone who has
been thinking about these technologies recently, and has been playing
about with [linkhut](https://linkhut.org/), something that been a bit
sad is the lack interoperability in terms of following & aggregation.
I intend to explore linkhut.
To address part of @asciimoo's comments, ActivityPub (to my ignorant
knowledge) is a different beast in so much as it requires dynamic
actions on the part of the server that are not possible with
statically generated sites or simple clients. If we are able to
standardize on a (auxiliary or otherwise) Atom feed format, then it
opens us up to passive listeners or statically generated/transient
systems should be able to consume and aggregate data more akin to RSS
readers.
Although this is an technical oversimplification and
misrepresentation, ActivityPub feels like a Atom/RSS-superset that
allows for user interaction that, while it is more powerful, is
technically more complex & demanding. However, I think in a bookmark
sharing system this doesn't _necessarily_ need to be the case. For
example, in linkhut, I can just copy a user's posted link into my
personal link feed. All that feature requires is a RSS/Atom feed but
without a standardized interface across similar platforms it could be
difficult to have bridges across these systems.
The Atom Syndication Format has everythig which is required for both
publishing and telecommunication.
I am currently working on a publishing system which is entirely made of
Atom documents.
https://journal.woodpeckersnest.eu/
https://git.xmpp-it.net/sch/Rivista
And there is also a potential for telecommunication from XMPP (Atom
Over XMPP), FTP, HTTP et cetera, due to the fine structure of Atom
documents.
**In terms of a project like buku,** Atom could easily be an export
backend. If I export the Atom xml to a path on my webserver (or a
static-site host), then I can serve my bookmarks to consumers without
needing a full ActivityPub instance. From there, users on other
services (or in their RSS/Atom readers) could aggregate what I'm
publishing and copy links as they please.
Did I mischaracterize the spirit of this idea @sjehuda ?
No. Not at al. I think that your descripion fits with my intentions.
However, I deem that The Atom Syndication Format (RFC 4278) and also
Feed Paging and Archiving (RFC 5005) have the means for best management
of bookmarks, bibliographies and other references, and for sharing of
bookmarks (e.g. YaCy, Searx, Mwmbl, et cetera), which I intend to
implement with "Blasta" (a similar system to linkhut).
Therefore, I think that designing the databse inline with Atom
documents, as specified in RFC 4287, be best to do.
|
Beta Was this translation helpful? Give feedback.
-
|
On Tue, 04 Nov 2025 08:24:09 -0800 Adam Tauber ***@***.***> wrote:
No standardization can solve the issue of a data provider deciding to
filter/limit the provided data.
Instead of talking about standardization, every system should provide
as much data/format as possible and users can filter it how they want
- in my opinion.
I agree.
This is more of a recommendation for bookmarks databases.
Database design require thinking, so designing a database which would
mostly fit to most, should be a good objective, I suppose.
It would also be easier to import and export, would it not?
|
Beta Was this translation helpful? Give feedback.
-
|
Friends. I have realized a structure of a database with 46 tables which resembles RFC 4287: The Atom Syndication Format. Please advise.
I made the directives of the database to which I call subscriber.sql https://github.com/user-attachments/files/24052057/subscriber.sql |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Good day, everyone!
I would want to have a discussion of standardizing bookmark databases/structures, including of extending them.
Projects with a common purpose
What are the most essential elements that bookmark databases should include?
Beta Was this translation helpful? Give feedback.
All reactions