home.social

#fep_0837 — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #fep_0837, aggregated by home.social.

fetched live
  1. I updated my proof of concept for #fep_0837 with Fedify. In the POC, you can now also use the FEP logic to purchase a certain quantity of a single item. You can test it out here: marketplace.playground.54grads This basically completes the POC 🎉
    The next goal is to implement this logic in a real beta version of the software, which, from an ActivityPub perspective, is the same, but includes real user sign-ups. This will result in a very very simple working shop system and a marketplace aggregating different shops, with the possibility of users buying certain products directly from the marketplace.
    #fedidevs #fedify #buildinPublic

  2. I updated my proof of concept for #fep_0837 with Fedify. In the POC, you can now also use the FEP logic to purchase a certain quantity of a single item. You can test it out here: marketplace.playground.54grads This basically completes the POC 🎉
    The next goal is to implement this logic in a real beta version of the software, which, from an ActivityPub perspective, is the same, but includes real user sign-ups. This will result in a very very simple working shop system and a marketplace aggregating different shops, with the possibility of users buying certain products directly from the marketplace.
    #fedidevs #fedify #buildinPublic

  3. FEP-0837: Federated Marketplace has been updated:

    https://codeberg.org/fediverse/fep/pulls/864

    I changed the activity names:

    - Offer to OfferAgreement
    - Accept to AcceptAgreement
    - Reject to RejectAgreement

    Now they are easier to process because they don't look exactly like regular Accept(Follow) activities and Mastodon's featured collection Accept activities.

    #fep_0837

  4. FEP-0837: Federated Marketplace has been updated:

    https://codeberg.org/fediverse/fep/pulls/864

    I changed the activity names:

    - Offer to OfferAgreement
    - Accept to AcceptAgreement
    - Reject to RejectAgreement

    Now they are easier to process because they don't look exactly like regular Accept(Follow) activities and Mastodon's featured collection Accept activities.

    #fep_0837

  5. RE: hollo.social/@fedify/019efa8c-

    I'm thrilled to have contributed my second PR to @fedify, which is now part of Version 2.3.0!
    #FEP_0837 is now fully implemented in the current version: w3id.org/fep/0837.

    But why is this interesting if you're a regular person who isn't interested in ontology and JSON-LD structure?

    With the basic concept of a Federated Marketplace, we could build a decentralised Amazon, Airbnb, BlaBlaCar, etc.

    Of course, it is already possible to use a different online shop for each of your needs. I do this personally, as well as for multiple organisations. It's always a lot more work than just buying stuff on Amazon, for example. For me, it's because Amazon has one basic workflow. Most sales are similar. I have a single history of orders, invoices, etc.

    I also ran an online shop and always sold more on other marketplaces than on my own shop.

    Good platforms are missing for other use cases. It would be great if every local tourist organisation could have its own domain and marketplace, and if I could also book in my preferred way (on another marketplace).

    It would of course take a long time to develop the software and then build up the communities, but I think it's possible!
    Here's the repo: codeberg.org/54GradSoftware/ec #economiverse

  6. RE: hollo.social/@fedify/019efa8c-

    I'm thrilled to have contributed my second PR to @fedify, which is now part of Version 2.3.0!
    #FEP_0837 is now fully implemented in the current version: w3id.org/fep/0837.

    But why is this interesting if you're a regular person who isn't interested in ontology and JSON-LD structure?

    With the basic concept of a Federated Marketplace, we could build a decentralised Amazon, Airbnb, BlaBlaCar, etc.

    Of course, it is already possible to use a different online shop for each of your needs. I do this personally, as well as for multiple organisations. It's always a lot more work than just buying stuff on Amazon, for example. For me, it's because Amazon has one basic workflow. Most sales are similar. I have a single history of orders, invoices, etc.

    I also ran an online shop and always sold more on other marketplaces than on my own shop.

    Good platforms are missing for other use cases. It would be great if every local tourist organisation could have its own domain and marketplace, and if I could also book in my preferred way (on another marketplace).

    It would of course take a long time to develop the software and then build up the communities, but I think it's possible!
    Here's the repo: codeberg.org/54GradSoftware/ec #economiverse

  7. @grindhold @Profpatsch
    Thank you for the update. I did some more local testing and I think the only problem preventing #fep_0837 from working is that an error occurs if "flohmarkt:data" is not available in the data. I think there is an issue with the implementation of activitpub.py at line 533.
    Here is a link to the error:
    md.c3fl.de/flohmarkt-error-mes

    Even if this is fixed, there is still the minor issue that the data is handled as if it were JSON, but it is JSON-LD. So the Proposal.resource.Quantity.hasNumericalValue is not deserialised like it is a JSON-LD. It still displays the object. :D See in the attachment.

    I'm not sure if this is intentional, but with the current logic, one can either create in Flohmarkt or federate a listing with a description including a Markdown link, which, when clicked on, will execute JS.
    I did create an example with just an alert. Like:
    [Click]:(javascript:alert(document.cookie))

    If that is easier for you, I can also create issues for the the points above.

    @silverpill

  8. @grindhold @Profpatsch
    Thank you for the update. I did some more local testing and I think the only problem preventing #fep_0837 from working is that an error occurs if "flohmarkt:data" is not available in the data. I think there is an issue with the implementation of activitpub.py at line 533.
    Here is a link to the error:
    md.c3fl.de/flohmarkt-error-mes

    Even if this is fixed, there is still the minor issue that the data is handled as if it were JSON, but it is JSON-LD. So the Proposal.resource.Quantity.hasNumericalValue is not deserialised like it is a JSON-LD. It still displays the object. :D See in the attachment.

    I'm not sure if this is intentional, but with the current logic, one can either create in Flohmarkt or federate a listing with a description including a Markdown link, which, when clicked on, will execute JS.
    I did create an example with just an alert. Like:
    [Click]:(javascript:alert(document.cookie))

    If that is easier for you, I can also create issues for the the points above.

    @silverpill

  9. @silverpill
    thank you for the response! I'm still new on this and json-ld seems to be quiet complicated.
    I have a question for this:
    > except that hasNumericalValue should be a decimal string, as you mentioned.

    This is what the #fep_0837 text says, but if I understand correctly, this is not a requirement of the valueflow context with the JSON-LD spec, but rather a choice of the FEP. Is the current output of the note conformative to the JSON-LD spec in this case? Why does the output need to be compared?
    Thank you in advance for your help!

    @grindhold @Profpatsch @fedify

  10. @silverpill
    thank you for the response! I'm still new on this and json-ld seems to be quiet complicated.
    I have a question for this:
    > except that hasNumericalValue should be a decimal string, as you mentioned.

    This is what the #fep_0837 text says, but if I understand correctly, this is not a requirement of the valueflow context with the JSON-LD spec, but rather a choice of the FEP. Is the current output of the note conformative to the JSON-LD spec in this case? Why does the output need to be compared?
    Thank you in advance for your help!

    @grindhold @Profpatsch @fedify

  11. @Profpatsch But why not just use AP for this? Fedifiy makes it easy. I can send structured JSON, and I can even make a compatible version for Mastodon. This text version may not be perfect, but it's certainly good enough. I think AP has many more advantages for this use case. Thanks to the actor and instance logic, you could, for example, choose to show or block certain canteens in your marketplace. For example, you could have a marketplace for your district or city, or one for a whole country with only vegan food.
    However, my main motivation is to experiment with the #fep_0837 functionality because I can and I like the technology. This may be a niche use case, but I think it's an interesting one. In the long term, it would also be possible for the canteens to receive feedback or answer questions from users. This would not be possible if it were just synchronising data via APIs.

    Going back to the original question: The above question applies to all time-based content. The best short-term solution would probably be to just repost in time for the note-centric AP world. The same "problem" applies to events in the Fediverse. I may announce the event a long time in advance, even though most of the information will only be relevant to users right before the event. The best long-term solution would be a really nice client that can differentiate between different content types and offer each one a good UX.

  12. @Profpatsch But why not just use AP for this? Fedifiy makes it easy. I can send structured JSON, and I can even make a compatible version for Mastodon. This text version may not be perfect, but it's certainly good enough. I think AP has many more advantages for this use case. Thanks to the actor and instance logic, you could, for example, choose to show or block certain canteens in your marketplace. For example, you could have a marketplace for your district or city, or one for a whole country with only vegan food.
    However, my main motivation is to experiment with the #fep_0837 functionality because I can and I like the technology. This may be a niche use case, but I think it's an interesting one. In the long term, it would also be possible for the canteens to receive feedback or answer questions from users. This would not be possible if it were just synchronising data via APIs.

    Going back to the original question: The above question applies to all time-based content. The best short-term solution would probably be to just repost in time for the note-centric AP world. The same "problem" applies to events in the Fediverse. I may announce the event a long time in advance, even though most of the information will only be relevant to users right before the event. The best long-term solution would be a really nice client that can differentiate between different content types and offer each one a good UX.

  13. Menuverse is a federated menu system for canteens and institutions, built on FEP-0837: Federated Marketplace, schema.org and Fedify/ActivityPub.

    https://codeberg.org/54GradSoftware/menuverse

    #fep_0837

  14. Menuverse is a federated menu system for canteens and institutions, built on FEP-0837: Federated Marketplace, schema.org and Fedify/ActivityPub.

    https://codeberg.org/54GradSoftware/menuverse

    #fep_0837

  15. flohmarkt now implements FEP-0837: Federated Marketplace!

    They add Proposal as an attachment to Note. Here's an example:

    https://kleinanzeigen.bonn.digital/~bonndigital/48a0e2b7-f0d0-421b-9190-cc15306be6a3

    I think Proposal properties could be added directly to Note to make the structure simpler. But an attachment is fine too.

    #fep_0837 #flohmarkt

  16. flohmarkt now implements FEP-0837: Federated Marketplace!

    They add Proposal as an attachment to Note. Here's an example:

    https://kleinanzeigen.bonn.digital/~bonndigital/48a0e2b7-f0d0-421b-9190-cc15306be6a3

    I think Proposal properties could be added directly to Note to make the structure simpler. But an attachment is fine too.

    #fep_0837 #flohmarkt

  17. Updating FEP-0837 (Federated marketplace): https://codeberg.org/fediverse/fep/pulls/693

    This PR adds a new recommended property to Proposal object:

    minimumQuantity

    #fep_0837

  18. Updating FEP-0837 (Federated marketplace): https://codeberg.org/fediverse/fep/pulls/693

    This PR adds a new recommended property to Proposal object:

    minimumQuantity

    #fep_0837